Hi Alex (and others)
Yes, the main issue is that we expose to many APIs which don't need
to be API especially in the UI. The core parts (e.g. tmf.core) are
usually in a much better shape. I'm not debating the clean-up
for the Neon release. I think everybody is on the same page to
have Trace Compass 2.0 for Neon. One thing we have to make sure
that the clean-up is done early (soon) and not postponed.
Otherwise we end-up in the same discussion after Neon.
Working on 2 branches with 2 different baselines are always
challenging, no matter which baseline is for master and which one
is not. Ideally we would work with only one baseline and on
master. But that's not the reality.
What I'd like to achieve is to have new features available for
Mars SR1 and SR2. Right now we already added some nice (smaller)
improvements to the Events Table which I'd like to have in SR1/SR2
and not only in Neon. Some others in the pipeline would be great
to have also in SR1/SR2 like dependency analysis or virtual
machine analysis view (hopefully it's possible with the current
API).
Please keep in mind that often user like to work with released
versions and not work on a nightly build. Released versions tell
them that there were some kind of quality assurance. Nightly
builds might be unstable. We are used to work with such
instabilities, but not everybody is. Especially, if they have to
work in tight deadlines. They don't have time to deal with these
issues and might not use Trace Compass then. We are not ready for
continuous deployment. We at Ericsson are working on increasing
the test coverage during CI but we are not there yet for
continuous integration. Too many manual test cases every release.
Increasing test automation should be an effort across companies
involved in Trace Compass.
What I would like to avoid is also that people change the API for
new features because it's easier to do so or because something is
not using the latest cool thing. Changes in APIs should make sense
and should add value. We should try to work with the existing APIs
as much as possible.
At last I think that which option we decide to go, all committers
from every company should work on getting valuable releases 1.x
and 2.0 for the sake of the overall project and it shouldn't just
be one company's responsibility.
When making our final decision we need to thing what would be the
least work for us to achieve the points above.
/Bernd
On 06/15/2015 03:55 PM, Alexandre
Montplaisir wrote:
Hi
Bernd,
As I pointed out in the other sub-thread, because we expose so
many APIs, I feel we are not in a very comfortable position right
now to commit to adding many features without bumping the major
version. Doing so would mean a lot of IThing2 workarounds, and
that's if we are even able to do so.
We've been asking ourselves this very question every cycle for the
last 3-4 cycles now. At some point we will have to bite the bullet
and do a major API cleanup, which will then allow us to commit to
a more stable API. But, of course, such cleanup is an API break in
itself...
No matter what branch 2.0 is, we should try to fit the cleanup at
some point within this cycle, so that at the same date next year,
we don't have to jump to 3.0 right away like we do now.
I agree with Marc-André, that normally master represents the
"latest". Here's an idea: instead of the stable-1.0 branch, we
could start a new "stable-1.x" branch, possibly after the chain of
move-to-subdir patches, so that we can continue to cherry-pick
easily. We've tried the merge workflow the past 3 times, maybe we
can give the cherry-pick workflow a try this time? (those patches
could bypass Gerrit to make it simpler, just like the merge
conflicts resolution also bypassed Gerrit the last few times)
Thoughts?
Alex
On 2015-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
|
