Hi Jonas, I am a bit confused by your dates here. The code freeze for v1.1 is 4/26 (or some time shortly thereafter), not some time in August. After 4/26 we will ideally only do small fixes requested by partners. Starting 4/1 the vendor already has started with QA, and the chipset vendor's QA timeline relies on there being a small delta between v1.0.1 and v1.1.
A freeze in the August/September timeline will be for 1.2. Maybe you mean that? And for that it absolutely makes sense to start with trunk again. Thanks, Andreas On Apr 3, 2013, at 9: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 _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
