On Wednesday 2013-04-03 22:20 +0200, Andreas Gal wrote:
> On Apr 3, 2013, at 10:12 PM, Justin Lebar <[email protected]> wrote:
> >> I agree that we did branch too early for the v1.0 release and my
> >> proposal does put branching at a later stage compared to when we did
> >> it for v1.0.
> >
> > Ultimately I think branching based on a date has been a mistake every
> > time we've done it in this project. We branch when we hit a date but
> > ship when we meet quality standards. It's easy to see how this leads
> > to branching way too early.
>
> I think this is as close as it gets to a silver bullet. I think in
> practice we will have to branch because there will be patches that
> people want to land that aren't meant for v1.1, or where we aren't
> sure it can go into 1.1 and we want to land them somewhere
> (trunk!). But we should try to keep trunk and v1.1 close to reduce
> the pain of landings to close to 0 (engineers don't have to do it,
> no conflicts). This is how we "branch when we are ready". When we
> think v1.1 is stable enough, we can let trunk float and absorb
> v1.2 work which will make it diverge and make uplifts hard, but at
> that point we will be ready for that.
What I learned about branchpoints from release cycles before we were
doing train-based releases was that we don't want to branch until
there's a substantial amount of pressure from people who want to
land stuff that's not for that release.
If the reason to branch is worry that developers might need to land
features for the next release, it's too early to branch. If the
reason is pressure from a handful of developers who want to land
features for the next release, it's still too early to branch. The
time to branch is when somewhere around half the developers on the
project are clamoring to have the trunk open because there's no
longer useful work they can do for the release that needs to branch.
Branching earlier leads to either or both of:
(a) extra work from maintaining branches
(b) loss of emphasis on the release as people move to trunk work
even when the release isn't done
and the upside of branching (letting development continue on the
trunk) isn't worthwhile until you have a significant portion of
developers who can no longer make useful contributions to the
current release.
That said, this experience is based on a model in which the trunk
can and should be restricted (eliminating the upside of branching of
reduced risk due to the restrictions). But I think that's a model
worth considering here, with weak restrictions (things needed for
release X, not an approval process, and only in the B2G-specific
areas).
-David
--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla http://www.mozilla.org/ 𝄂
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
