Hi, > I agree with all of this on a general level: we need to find a process > to stabilize the release in the end of cycle. > > There are 2 ways of doing this: > - policing the commits: that's basically Alec's proposal here above > - branching: used in other Open Source projects (see Fogel's) > > I think we can go away with policing right now because we do not have a > lot of outside contributors with commit privileges. We can therefore > hold on patches during the end of cycle phase. Note that this process > may stall some developers (working on feature straddling 2 releases for > instance). Those can always create their own working branch (as Andi did > at the end of 0.6 for instance) but that's a burden on them to merge > everything back once the release is declared. > > Branching is less constraining from a development standpoint but there's > the added burden of committing to 2 branches for a substantial amount of > time, something we may want to avoid right now. Eventually (when we have > a big enough community of committers), branching might be the only way > to go though.
This relates, I think, to how atomic our commits are. One of the points in the Fogel book seemed to be that it's important to make atomic commits, splitting changes into the smallest logical part. I think if we did that more consistently, the pain of committing to two branches would be somewhat lessened. I'm not sure I actually *like* asking people to consistently split their commits up, though. It's very convenient to make a variety of changes in one commit, at our current size this doesn't feel like a major problem, and it's certainly a widespread practice. But perhaps it's worth thinking about. Sincerely, Jeffrey _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
