Re: [tracecompass-dev] Master branch: 2.0 or 1.1 ?

[Geneviève Bastien <gbastien+lttng@xxxxxxxxxxxx>]

On 06/15/2015 05:02 PM, Matthew Khouzam wrote:
>
> Ok, it's good that this is cleared up, I think we are down to the core
> of the matter: who maintains the features/bugfixes and how is it done. I
> think the worst thing possible would be for Ericsson to work on 1.1 and
> Efficios on 2.0 then we cross cherry-pick. I also think we are at a
> point where meeting in person will really help clear things up. On
> Wednesday we do have a meeting, we should discuss this in person and
> then post the results on the mailing list so that others can see our
> conclusions and comment on how right or wrong we are.
Is anyone from Poly attending this? I feel there should be...
>
> Just a little external thingy to think about: researchers doing their
> masters normally have their code ready 1 month before they present their
> theses. They also graduate in may. It would be a nice for them if we
> merge their code in 1.x so that they can show off their work asap to
> prospective employers. 
The ttm (time to master) is usually around 6 months, but may be a little
more this year, as there are many graduations and fewer staff.

Anyway, I don't think the 1.x argument matters here: researchers use the
latest and greatest and that's what they'll show to their prospective
employers. It might now even be in 2.0 yet! ;-)
> On a business side, we do have many features that
> would be nice to share Asap. Would cherry picking, especially after the
> great directory schism of 2015 not be much harder and thus less tempting
> to do? I for one hope the lazy solution is often the best one. ;)
directory schism... I foresee headaches... It's like the renaming
everything to tracecompass all over again!! ha! But yeah, it's for a
good cause... again...

>
> I am really warming up to keeping 1.x as master and neon as new feature
> development with maybe weekly merges. Genevieve did something similar
> for polytechnique. I think her experience and expertise would be quite
> valuable in this situation.
Yes indeed, I had a Polytechnique experimental branch, that made changes
to classes and API, and that I tried to keep up with the master. As long
as the 2 branches do not touch the same files too much, it's all good,
but the minute you do parallel work on files, merging becomes hell. What
I foresee will be the most problematic if the 2 branches are actively
worked on is when 2.0 breaks, cleans, removes from the API of class X
and 1.x adds and improves that API, then all patches using that API will
have conflicts, that will have to be solved, then unit tested (and unit
tests fixed/modified if required). That will be a completely different
patch from the original and it will have to go through full gerrit
review again to make sure the cherry-picker did a good job porting it.
And by november, we'll all just push to 2.0, it's less pain.

Oh and the worst conflicts... is when directories are renamed, and the
other branch worked (and keeps working) on the old files. There was a
few of those last year (linuxtools->tracecompass, lttng2.stuff,
os.linux, etc). So if you can guarantee, 100% (special look at Alex
here) that the directory schism is the last rename of this cycle, then
it might not be too bad.

I'd like to say "don't break the API for now and work on 1.x", but it's
already too late it seems. My own patches waiting on gerrit do break the
API.

And +1 on cleaning the API this cycle!

Also, would it be possible to have API incubation? Something like, "this
is a class of tmf.core, that will be used by other plugins, so it's part
of the API, but that API may not be final, so be aware it might change
at anytime". It could be put internal, then x-friend with other plugins,
but tmf.core is not supposed to be aware of lttng2.kernel.core for
example. Because some times, we quickly develop an API in mars and
realize in july that a method is not exactly how it should be... oops...


Cheers,
Geneviève

>
> BR,
> Matthew
>
> On 15-06-15 04:12 PM, Alexandre Montplaisir wrote:
>> Hi Matthew,
>>
>> It's the same merge conflicts more or less. The *major* pain is the
>> accumulated pain from all the minor conflicts ;)
>>
>> But whoever is not "the" master branch has to play catch up all the
>> time (either merging to a tracecompass-neon, or cherry-picking wanted
>> patches to stable-1.x).
>>
>> Let's look at it this way: if Ericsson wants a 1.1 branch, then I
>> think Ericsson should carry the burden of it. At EfficiOS we feel that
>> maintaining a 1.1 branch right now is not a good investment of our
>> time, because the APIs are in such a bad shape. That will hopefully
>> change if we clean it up during 2.0. That and Java 8 default interface
>> methods, but that is another big discussion ;)
>>
>> Cheers,
>> Alex
>>
>>
>> On 2015-06-15 03:42 PM, Matthew Khouzam wrote:
>>> Hey Alex,
>>>
>>> A heads up: we discussed this and all seem to agree with M-A internally.
>>> I am curious, would the *major* *pain* from the merges be equal to the
>>> *minor* *pain* of every cherry picked patch? especially after the code
>>> move? Basically, would it be that we were forced to do work we were
>>> putting off or is it additional labour?
>>>
>>> Matt
>>>
>>> On 15-06-15 03:25 PM, Bernd Hufmann wrote:
>>>> Hi Alex
>>>>
>>>> I have a similar concern as Marc-Andre. If we aim for 2.0 in master
>>>> right away (option 1), my concern is that Mars SR1 won't get much
>>>> attention and new features won't be included in SR1. Developers tend
>>>> to not backport them to older release baselines. That means that users
>>>> of Trace Compass who rely on released versions (not nightly builds)
>>>> would have to wait till June 2016 to get these features. I'm not sure
>>>> how we can make sure that certain features and bugfixes would be in
>>>> SR1 and later SR2 if we go with option 1. Any thoughts?
>>>>
>>>> Bernd
>>>>
>>>>
>>>> On 06/15/2015 01:14 PM, Marc-André Laperle wrote:
>>>>> Hi Alex,
>>>>>
>>>>> The way I see it, the major difference between 1) and 2) is which
>>>>> version do we perceive as our main focus and what we want the
>>>>> community to see as the main focus. Contributors just clone and start
>>>>> working on master. I think for us (at least at Ericsson?) the main
>>>>> focus is 1.1. If master is 2.0, there are some concerns that people
>>>>> will not take care of backporting everything of value to 1.1 and the
>>>>> SR1 release will be light on content. But I do like the simplicity of
>>>>> master being "the latest and greatest" with everything permitted. I'm
>>>>> not sure it's enough counter weight to the risk of not having a
>>>>> feature rich 1.1.
>>>>>
>>>>> Marc-Andre
>>>>>
>>>>> ________________________________________
>>>>> From: tracecompass-dev-bounces@xxxxxxxxxxx
>>>>> [tracecompass-dev-bounces@xxxxxxxxxxx] on behalf of Alexandre
>>>>> Montplaisir [alexmonthy@xxxxxxxxxxxx]
>>>>> Sent: Friday, 12 June 2015 11:03 AM
>>>>> To: tracecompass-dev@xxxxxxxxxxx
>>>>> Subject: [tracecompass-dev] Master branch: 2.0 or 1.1 ?
>>>>>
>>>>> Hi all,
>>>>>
>>>>> Branching off (pun intended) the discussion here to talk about our
>>>>> branching strategy for SR releases and Eclipse Neon.
>>>>>
>>>>>    From the way I see it, we basically have 2 options:
>>>>> 1) Bump master to 2.0 right away, allowing API breaks all around. Then
>>>>> build the SR releases from the stable-1.0 (which would rather become a
>>>>> stable-1.x) branch.
>>>>> 2) Bump master to 1.1, and build SR releases from there. Since You
>>>>> Can't
>>>>> Stop Progress (tm), this would imply having to create a -neon branch,
>>>>> which could contain API breaks, and to which we would regularly merge
>>>>> from master.
>>>>>
>>>>> I am strongly in favor of option 1). We used the option 2) workflow
>>>>> back
>>>>> in Linux Tools for about one full release and a half, and it was a
>>>>> *major* *pain*.
>>>>>
>>>>> To show how limiting it is to not allow API breaks in master, consider
>>>>> this : 1.0 is not even released yet, and we already have such API
>>>>> breaks
>>>>> in master!
>>>>> (About this, I recommend to all contributors to setup their 1.0
>>>>> baseline
>>>>> in their workspace, so that they can be made aware of these breaks. It
>>>>> is now much easier to do, thanks to targets-as-baselines. I have
>>>>> updated
>>>>> the instructions to do so at [1].)
>>>>> So if we were to go with 2), we would have to rectify this first.
>>>>>
>>>>> Thoughts, comments?
>>>>>
>>>>> Cheers,
>>>>> Alex
>>>>>
>>>>>
>>>>> [1]
>>>>> https://wiki.eclipse.org/Trace_Compass/Development_Environment_Setup#Define_an_API_baseline
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> tracecompass-dev mailing list
>>>>> tracecompass-dev@xxxxxxxxxxx
>>>>> To change your delivery options, retrieve your password, or
>>>>> unsubscribe from this list, visit
>>>>> https://dev.eclipse.org/mailman/listinfo/tracecompass-dev
>>>>> _______________________________________________
>>>>> tracecompass-dev mailing list
>>>>> tracecompass-dev@xxxxxxxxxxx
>>>>> To change your delivery options, retrieve your password, or
>>>>> unsubscribe from this list, visit
>>>>> https://dev.eclipse.org/mailman/listinfo/tracecompass-dev
>>>> _______________________________________________
>>>> tracecompass-dev mailing list
>>>> tracecompass-dev@xxxxxxxxxxx
>>>> To change your delivery options, retrieve your password, or
>>>> unsubscribe from this list, visit
>>>> https://dev.eclipse.org/mailman/listinfo/tracecompass-dev
>>> _______________________________________________
>>> tracecompass-dev mailing list
>>> tracecompass-dev@xxxxxxxxxxx
>>> To change your delivery options, retrieve your password, or
>>> unsubscribe from this list, visit
>>> https://dev.eclipse.org/mailman/listinfo/tracecompass-dev
> _______________________________________________
> tracecompass-dev mailing list
> tracecompass-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/tracecompass-dev