On 5-12-2012 4:13, Ted Gould wrote:
On Tue, 2012-12-04 at 14:40 -0800, Josh Andler wrote:
On Tue, Dec 4, 2012 at 1:50 PM, Martin Owens <doctormo@...400...> wrote:
If we have a release schedule and we've reached a feature freeze, we should have branched into a release branch at that point. Trunk shouldn't ever be blocked with feature freezes, but instead making sure bugs get fixed in both trunk and release branches is a chore for us developers.
This is not how our development process has worked in the past. Which is why I put it forth as an idea to branch 0.49. We've previously opted to not actually branch for release until the release was ready as opposed to at freeze.
Perhaps we should put this proposed change in processes up to a vote (along with any other reasonable suggestions) a few days of waiting for feedback.
The concern has always been effectively dividing the workforce. If no one ends up making that release, what state are we in? Sure, Bazaar helps here, but it seems like the project suffers a bit overall. TBH, we have done that a bit in the past. Bryce did release management on 0.44 I believe on a branch in a similar style (as much as SVN allows it) and that was a frustration that he expressed.
Realistically, there's no difference to forking off a release branch and telling devs to keep their features on feature branches. In neither case is anyone "blocked" it's about naming really. So I don't think we should look at it as blocking anyone's progress either way.
I think the difference is in who gets extra overhead: the bug fixer or the feature coder. If we would have a 'release' branch for too long, one would have to apply bugfixes to both 'release' and 'trunk'. Backporting is no fun at all, so... I'd much rather put the merging/whatever burden upon the feature coder.
Personally, I guess I want to see the release as "happening" which I think is the main concern. If it's well on it's way to being complete it's just baking and fixing, then sure, I'm for it. So what I'd propose is that we need to find people to assign to the bugs who are willing to take responsibility for fixing them. When they're all assigned, I think it might make sense to do a release branch.
Branching right before people are going to fix bugs sounds very sadistic and is not motivating at all! ;)
I think the problem now is that it all takes long. It doesn't mean the "system" we have is broken, just that it is unfriendly for feature-coders during stretched out freezy phases. So be it.
Have a look at the graphs here: https://www.ohloh.net/p/inkscape/contributors/summary We are getting by with only a few coders, so things are going slower than people may hope. Take note: 10 committers per month on average.
Branches are pain. Let's not make it hard for ourselves.
Cheers, Johan