To bring us back to the main topic of this thread. All developers in this thread has said that there is significant cost to staying on the branches that way we currently do. Part of that cost is the approval process, part of it is the uplifting of patches.
This matches what I've heard talking to engineers. I'm really inclined to believe this to be true. I would encourage others to as well. This doesn't mean that we've failed to help engineers with making the process simpler. It surely would be a lot more painful if we hadn't had people to help with uplifts or people to go through approvals as often as we do. But we are still spying a high cost by staying on the b2g18 and v1-train branches. I agree that there's an unknown amount of risk in going back to m-c and gaia master. But there is also an unknown amount of risk in all the merging that we are doing. And the regressions associated with switching brances is something that would happen now and that we would have between now and August to fix. Regressions due to nerves happen all through development, up until the day we codefreeze. Current estimates of number of remaining bugs we have ahead of us is in the several hundreds. This is a significant amount of work. The risk of not being able to finish that on the current schedule is also something we need to take into account. This is as of right now my biggest concern. Together with the general unhappyness from engineers with the current branch handling. Note that under the plan I'm proposing we would leave m-c and gaia master in early may. That means that that is when gecko goes into a much more aggressive stabilization mode than we ever have had for b2g code. So at that date is when our risk management through approvals would essentially be the same as what we have now. I.e. the main source of risk would be due to required b2g patches landed to fix blockers. Also note that by "code freeze" on Aug 12th, I'm referring to a phase that we haven't yet reached for the v1.0.1 release, I.e. no more checkins allowed *at all*. / Jonas On Apr 3, 2013 12:16 PM, "Jonas Sicking" <[email protected]> wrote: > Hi All, > > It's come up a number of times that there are a fairly large number of > issues with the way that we're using "v1.1 branches", i.e. b2g18 for > Gecko and v1-train for gaia. > > I won't go in to the various issues here since I think it's generally > agreed that it would be good if we could avoid them. > > The current release plan for v1.1 means that we have code freeze on > August 12th. This is the date when, as I understand it, we absolutely > have to be done with the last line of code and it's pencils down for > everyone. > > This actually means that we would have the ability to go back to > mozilla-central and gaia master right now and ride the normal release > trains for the Gecko 23 release, while still reaching the release > milestone for gecko before v1.1 is done. > > This has a lot of attractive features: > * No backporting work for now! > * Much simpler backporting work once we branch for aurora on may 13th. > * We spend more time writing code and less time porting it. > * Less risk involved when backporting patches. > * We pick up a whole host of bug fixes and new features that's > happened since Gecko 18 branched. Including performance work. > > However there are quite a few things that we need to check before we > can make such a move: > * Will it affect our partners ability to upgrade 1.0 users to the 1.1 > release? > * Are there any big and scary landings that are planned for the Gecko > 23 release that we'd rather not take. Gfx layers-refactoring comes to > mind. > * Will we be able to take security fixes that are landing in Gecko 23 > all up until August 6th? > * Is mozilla-central and gaia master working well enough right now for > Firefox OS that this is an option? > * Will all relevant partner testing still be possible even through > we'll be on mozilla-central for some of it. > > We also have to develop a plan for what to do if we need to fix some > Gecko issue that requires large enough changes that we can't land it > in the Firefox release trains. At that point we have to branch away > from the normal Firefox release branch. This means that all fixes that > go into the Firefox branch will have to also be ported to the B2G > branch. > > All in all I think the advantages outweigh the disadvantages here. > Things from Firefox development landing in aurora and beta tend to be > very safe. Definitely safer than the sum of the large amounts of work > we'll still be doing for B2G. So if we can work through the issue list > above, I think we should do it. > > Would love input from both developers and product on this. > Unfortunately I'll be on vacation thursday and friday so it would be > great to get help driving looking into the checklist above during that > time. > > / Jonas > _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
