9:05 a.m.
On 22/08/12 16:56, Dave Neary wrote:
Hi,
On 08/22/2012 11:02 AM, Livnat Peer wrote:
> About branching policy I'm not sure if we have one, except for creating
> a branch before release for stabilization.
Allow me to rephrase & make this concrete:
In the GNOME project, modules branch as close as possible to release -
usually on the release day, or when making a release candidate. In
effect, the developers agree to work on new features only on branches,
and the trunk is where most of the pre-release work gets done. Branches
get merged back into the trunk when they're ready, and not before - and
never when we're in feature freeze.
We branch a stable branch for fixes to bugs in the stable release, and
those are as a matter of course fixed in trunk first, and back-ported to
the stable branch. We have time-based stable releases of the stable
branch during the first 6 weeks of a release cycle to get those fixes
out to distros & users.
My understanding of what you've said so far is that at some point (long
before the August 8th release date), a 3.1 release branch was made, and
only bug fixes to features which had been included in 3.1 were added to
that branch from that date. In the meantime, feature and bug fixing work
continued also on the stable branch, but not all of those bug fixes were
back-ported to the pre-release branch. I'm guessing that branch was made
when we hit 3.1 feature freeze?
If my understanding is correct, you then have a period of several months
(because of the release date slip) when the 3.1 branch is not moving
very much, and everyone is working on the trunk branch, including
developing new features. The end result is that when the release is
made, there is already a big diff with trunk, and as you point out,
cherry-picking bug fixes for inclusion on a 3.1 branch is a lot of work.
In my mind, the work on 3.2 started when we made the 3.1 branch, in this
scenario, so perhaps we're already too late to discuss what needs to be
included in the 3.2 release - perhaps we should simply work on
finishing/stabilising what we have now for release?
+1, I suggest that instead of stabilizing what we have now, we'll send a
release date and a feature freeze (FF) date to the dev lists, and see if
there are any comments about the plan, maybe postponing FF by a week or
so can give us more features etc.
On the agreed FF date we'll create the 3.2 branch and ask all
stabilization patches to be cherry picked to the 3.2 branch.
I think we should discuss now what should happen with the next-next
release :)
after releasing 3.2 we'll have the same dilemma we are having today. How
will we make the decision if the following release is 3.3 or 3.2.1, do
we want to create 3.2.1 on our 3.2 release date and ask for all
stabilization patches to be back ported there? and if we see that we
want to release 3.3 at the end and no need for 3.2.1 will all the cherry
picking be for vane?
Again, excuse me if I'm over-stepping bounds, I'm just trying
to figure
out where the work in the project is getting done, and what that implies
for this thread.
I think it is a useful discussion and can help us going forward. There
is a great value in your participation and in any experience someone
brings to the table.
Cheers,
Dave.