[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tracecompass-dev] Master branch: 2.0 or 1.1 ?
|
On 2015-06-15 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.
No, of course not, that would not be a viable option. The two viable
options are:
1) Create a tracecompass-neon for 2.0, keep master at 1.1, merge from
master to t-n once in a while.
2) Create a stable-1.x, bump master to 2.0, push everything to master
first, then cherry-pick all wanted stuff in stable-1.x
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.
Sure, I've asked Dominique to add it to the agenda.
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.
That should not be affected by the current branching discussion, because
(n+1).0 becomes the main branch after SR2 in February usually.
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. ;)
No no, both branches would start after the Great Directory Schism (I
like that name ;) ), so cherry-picking remains easy.
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.
Indeed! From what I understood her experience was "so frustrating she
thew in the towel" ;) But let's hear her comments.
Cheers,
Alex
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
