Unfortunately it's not the case that we'll do only small fixes post 4/26. First of all the current leo+ list is bringing us past 4/26, and we'll have plenty of leo+ bugs filed between now and then. Additionally, we're expecting very large number bugs to be filed in response to testing that's starting after 4/26.
So the amount of code churn that we'll get from aurora and beta landings I would expect to be dramatically smaller than the amount of code churn that we'll be doing specifically for B2G no matter which branch we are on. / Jonas On Wed, Apr 3, 2013 at 12:35 PM, Andreas Gal <[email protected]> wrote: > 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
