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. 2. Ride the X train. If X=18, we can do that, but it means landing hundreds of b2g18 patches that are not on firefox18 on firefox18. If you can convince the Firefox release drivers to take those on the ESR, I am ok with this approach, but I don't see the benefits. The general complication here is indeed not the influx of aurora/beta fixes into b2g, its really the other way around that I see as problematic. Andreas > > / Jonas _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
