> 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.
I share engineering's desire to move to tip of our branches as soon as possible, but in our conversation I noted that it was a blocker from previous partner qualification/update conversations (we can revisit with partners) and that it would also be very difficult to evaluate how many regressions we'd be introducing by taking m-c/master as v1.1. It may put us in another 1.0 situation all over again. -Alex On Apr 3, 2013, at 1:20 PM, Jonas Sicking <[email protected]> wrote: > 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 _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
