> I think SR1 should be focus on stability - but right now it is "whatever" happened to be in master.
Master is not an "open" branch in which we can put anything. Or at least, it has not been used that way since I joined the project. Master contains bug fixes and features that are ready to be released. This should be even more true considering some
people regularly release to their users using a nightly build. Features that are not ready should stay in Gerrit, or get their own branch.
The agreement last August was that we wanted to release features to CDT users faster than once a year, and also that to minimize overhead, we would stay aligned with the release train. So, for a year now, we were following a plan to release 8.5 at Luna
SR1. From this list, I get the impression many committers were working based on that assumption.
For better or worse, I think it is too late, one week before RC1 to change those plans. I don't think that is fair to committers, consumers or even users. Furthermore, we are mid-August and more than one of us are on vacation,
so we have no guarantee committers will be able to cherry-pick commits as we are unexpectedly asking them to.
So, I think we should follow our commitment to release off the master branch for this release. We can continue the discussion about what would be the best release process going forward.
I'll take care of the release review since Doug is busy, although I'll need some pointers as to where/how to get started.
To summarize, my vote is that
- we release 8.5 off master
- we create an 8.5 branch after the RC1 build which will keep master open for new work
- we continue the discussion about CDT release schedule
Since this follows our original plan, I'm hoping it will cause the least disturbance.
Are people on board?
From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Alena Laskavaia [elaskavaia.cdt@xxxxxxxxx]
Sent: August 14, 2014 8:39 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Releases
To Marc's point about re-testing if he cherry picks debug fixes - you were planning to re-test this anyway. With
controlled numbers of fixed it will be actually a lot easier to a) test b) do a release bureaucracy
And you don't have to cherry pick ALL bug fixes in debugger - only critial/most wanted ones. Same goes for other components.
I think SR1 should be focus on stability - but right now it is "whatever" happened to be in master.