> 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. On Wed, Apr 3, 2013 at 4:03 PM, Jonas Sicking <[email protected]> wrote: > Yeah, I don't believe we have the luxury of being "done" before > branching to aurora. That's certainly where we should eventually get, > but we have too many table-stakes features still to implement that we > can't put a 12 week gap at the end. > > 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. > > / Jonas > > On Wed, Apr 3, 2013 at 12:59 PM, Andreas Gal <[email protected]> wrote: >> >> The vendor predicts that they will file around 300 regressions during the QA >> cycle (between now and August). I don't think we want to fix that on Aurora >> or Beta, and "lets just slip 6 weeks" is unfortunately not how the hardware >> business works. We are currently closely tied to hardware schedules because >> we are supporting individual hardware launches with software. The goal is >> over time to switch to a reference software model where we make a golden >> reference for a specific platform (a real hardware platform, or even just a >> reference platform), and OEMs make products out of that (similar to the >> Android model). Its clearly not a model where we have arrived at yet. For a >> while we will have to continue to be closely involved in the actual product >> engineering. In a year or two ideally we will be closer to the reference >> platform model, and in that world riding trains makes sense, and slipping >> will be an option. >> >> Andreas >> >> On Apr 3, 2013, at 9:41 PM, Justin Lebar <[email protected]> wrote: >> >>> This is similar to what we did with 1.0. We rode the trains until >>> beta, then we branched. >>> >>> The problem was, we branched too early. We thought the branch would >>> stabilize for a few weeks before we shipped, but in fact b2g18 has >>> been stabilizing for months and still isn't ready to ship as v1.0.1. >>> >>> To avoid making the same mistake again, I think we'd probably want to >>> say that we're not going to branch. That essentially means we need to >>> be done when Aurora branches to Beta, because changes on Beta are >>> (rightly) highly restricted. >>> >>> If we're not ready by the time we hit Beta, we slip by 6 weeks. We >>> don't put our beta users at risk for breakage to make our b2g >>> deadlines. >>> >>> Note that we'd still be double-landing most patches on aurora and m-c, >>> because we will inevitably be under a huge amount of schedule >>> pressure. But that's a heck of a lot better than double-landing on >>> b2g18 and m-c. >>> >>> On Wed, Apr 3, 2013 at 3: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 >> _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
