Agreeing with everybody, even though there is a bit of a disagreement :-) There is the "right thing" and the "thing we have to do". I know it's hard for me to talk about "things we have to do" because, well, that leads to imperfect world.
The reason the trains work for us is because we have everybody looking at nightly, so by the time we start slowing down for Aurora and Beta, we know we're in decent shape, and we know we can change our behaviour, lock things down, and hit the dates for shipping. With the current setup, we have a large group of people, with a large set of tests, get on the train late and introduce the work that we're not used to doing at that stage of the game. To beat the analogy to death, it seems like we should have another station, or another set of tracks for them. In the perfect world though, they would be on the train from day one, and not surprise us and themselves with all the work way late in the game. I'm getting to the point - if our partners can get on the aurora train right now (22), then maybe there is enough time to ship based on that version. I doubt our partners will go for it, but it would be something to start planting now. As for riding the 23 train, I like to think I'm brave, but that one scares the crap out of me, with a few working days between us producing a build and pencils down. Milan On 2013-04-03, at 3:55 PM, Andreas Gal <[email protected]> wrote: > > Whatever we have to land on the branch, landing more than what we have to is > not an option. Starting 4/26 the chipset vendor and the OEMs drive and decide > what patches they take since they will be in an active QA cycle. Every time > we touch the code we risk breaking something, so they will want to minimize > changes (this is not a guess, I know this is the case with them). They will > not take any patches they don't request. If we dump our trunk on them through > August, it will be completely impossible for them to stabilize and they will > have to fork internally. The result will be a lot of invisible breakage we > don't understand because they will start reporting bugs against a branch we > can't see or reproduce. We worked very hard to have these publicly visible > "vendor" branches. They make us much more open than any other open source > project involving hardware. Losing this benefit and openness would be > extremely bad, in my opinion. > > I agree with what Justin said though. We should avoid branching too early. We > should hold off 1.2 work until 1.1 is in good shape and not changing much any > more. That will avoid difficult uplifts. Already today most of the uplifts > are not done by engineers because they are trivial. It would be good if we > can keep it that way. > > Andreas > > On Apr 3, 2013, at 9:47 PM, Jonas Sicking <[email protected]> wrote: > >> 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
