On Wed, Apr 3, 2013 at 1:16 PM, Andreas Gal <[email protected]> wrote: > > On Apr 3, 2013, at 10:07 PM, Jonas Sicking <[email protected]> wrote: > >> On Wed, Apr 3, 2013 at 1:01 PM, Milan Sreckovic <[email protected]> >> wrote: >>> 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. >> >> As far as I know, we have shipped 16 releases of Firefox using the >> train model without ever being more than a few days late. So I'm not >> worried about having the non-b2g parts of gecko ready for the target >> date here. There's a lot more risk in the B2G work, but that risk is >> unaffected by which train we are on. >> >> In fact, optimizing for reducing that risk means that we should do >> whatever makes b2g development easiest. And the shorted distance that >> we have between m-c and the train we are shipping, the easier writing >> b2g code is. > > You are asking for different things here. You are proposing two things. > > 1. Switch from 18 to 22 for v1.1, which means taking hundreds or thousands of > patches that were never tested or certified as part of v1.0, dramatically > changing our risk profile. This is a complete no-go for our partners. We can > keep arguing about this, but it will absolutely not happen. You have the > vendor contacts yourself. Feel free to reach out and ask.
Yup. This was one of the points that I listed in the original emails. I don't want to speak for Alex, but I *think* that he has offered to do this. FWIW, I think the large number of patches that we've taken for B2G since certification poses a much larger risk than the gecko patches that we are talking about here. Simply because the B2G patches are much closer to the relevant code. / Jonas _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
