Hi Daniel, Can you speak to this point Jonas made from your perspective?
>>>>>> * Will it affect our partners ability to upgrade 1.0 users to the >>>>>> 1.1 release? Update size would increase, and we can't yet say how many regressions we've taken between master/m-c and v1-train/m-b2g18. -Alex On Apr 3, 2013, at 1:39 PM, DANIEL JESUS COLOMA BAIGES <[email protected]> wrote: > > > On 4/3/13 10:13 PM, "Andreas Gal" <[email protected]> wrote: > >> >> On Apr 3, 2013, at 10:07 PM, Justin Lebar <[email protected]> wrote: >> >>>> "lets just slip 6 weeks" is unfortunately not how the hardware >>>> business works. >>> >>> If the past months have taught me anything, it's that "let's just >>> branch and double-land everything" is unfortunately not a path to >>> shipping quality software on time with happy, productive engineers. >>> So this is not a one-sided trade-off. >>> >>> I get that there are partner constraints here, and perhaps riding the >>> trains is incompatible with them, but I think there's a certain amount >>> of creativity called for here, given that what we've been doing hasn't >>> been working. I'd be curious to know if you have any ideas in this >>> respect beyond "wait a few years". >> >> I don't think there are any silver bullets I can offer. What exactly is >> the problem we are trying to solve here though. How often do people still >> have to double-land themselves? The feedback I was getting is that the >> vast majority of landings is done by our awesome uplifting mini-team. In >> rare instances people have to help directly (thats what we should try to >> reduce by keeping trunk and v1.1 close as long v1.1 is still changing). >> Is this accurate or do you feel that uplifting is still a pain? >> >> Andreas > > Until a couple of weeks ago that was not a big problem (although the > number of times devs needed to help uplifting sheriffs has not been low), > now that new features are being uplifted to v1-train the number of times > in which people need to create branch-specific patches is increasing. This > is a heavy burden, especially now that we are under pressure to deliver > 1.0.1 and the certification process is likely to raise many bugs. > > Apart from that, I think the level of control we are enforcing to land > things in v1.1 is high, that means that v1.1 and master are not that close > either. > > I am not saying I have a solution for this, but that these points are > definitely reducing team productivity *a lot* > >> >>> >>> On Wed, Apr 3, 2013 at 3: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 > > > ________________________________ > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar > nuestra política de envío y recepción de correo electrónico en el enlace > situado más abajo. > This message is intended exclusively for its addressee. We only send and > receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > _______________________________________________ > 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
