Having real-time (or short-delay) mirroring of Google's trees into the Android Open-Source Project isn't going to happen in a reliable way.
There are too many things that can go wrong with such a plan, too many reasons why code drops could need to be stopped for long periods at a time. Those reasons aren't gonna go away. Even if we did try to make frequent drops when it's possible, we need to anticipate that there'll routinely be long periods of time when that's not possible - in the last 6 months we've been through 2 periods of 2 months and 1 period of 1 month when no drop has been possible, i.e. more than 80% of the time (and in 2 of those 3 occurrences we broke out of those situations by releasing snapshots with no history). So, really, we (Google) would be incurring the process costs of being able to make short-delay code drops while exposing ourselves to pressure from people and organizations who thought that they could rely on constantly receiving frequent drops. Not making intermediate code drops is a win-win-win situation: -Users don't get misled by unscrupulous rumor-mongering bloggers into believing that some features will exist in a given release when there's no certainty about that. -OEMs that work from the open-source tree don't need to choose between using the latest and greatest open-source tree and using a tested tree that receives few changes. They can have both at the same time. -Google doesn't need to worry about the complexity of doing short-notice code drops out of a fast-changing tree that doesn't match any shipping devices - that saves us a lot of time and energy that can be spent on other aspects of the Android Open-Source Project. JBQ On Mon, Jul 27, 2009 at 7:17 AM, Al Sutton<[email protected]> wrote: > > There is always turning things on their head so that the Goog repository > feeds off the open source one to avoid big code drops. > > The more successful projects I've worked on branched late and the initial > work on the branch was dropping infeasible features (usually infeasible due > to time constraints). The more problematic and stressful projects have been > the ones where features creep until someone says "Blimey, we need to make a > release", then everyone pulls long shifts trying to get everything together. > > I'm not suggesting we ban new development, that can always go in master, but > adding new features to a branch (e.g. the AVD gui) should be an exception > situation and not the norm. > > Al. > > -- > > * Written an Android App? - List it at http://andappstore.com/ * > > ====== > Funky Android Limited is registered in England & Wales with the > company number 6741909. The registered head office is Kemp House, > 152-160 City Road, London, EC1V 2NX, UK. > > The views expressed in this email are those of the author and not > necessarily those of Funky Android Limited, it's associates, or it's > subsidiaries. > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Jean-Baptiste Queru > Sent: 27 July 2009 14:59 > To: [email protected] > Subject: [android-discuss] Re: What is Donut? > > > 1) This situation is exactly what I'd expect as an engineer working on > such a large project, and I've seen it at every one of my jobs so far. > The requirements and schedules change based on changing conditions in > the ecosystem and based on technical constraints that get discovered > during development. Other than at the very end, the state of the > development tree doesn't quite match the set of requirements. > > 2) From my point of view, it's not different from what happened with > 1.5, 1.1 or 1.0 (other than the fact that this time the version number > isn't known ahead of time). In each of those previous cases there was > an ebb and flow of features being added to, modified in or removed > from the release plan, with the actual code in the tree and the > release plan only converging quite late in the cycle, and donut isn't > any different. The actual gap between the code in the tree and the > final feature set in the matching release varies from one release to > the other, which is actually expected given the amount of > unpredictability involved. > > 3) Good question. More importantly, what do we (Google) do to avoid > such situations in the future? (More precisely, as "Mr Android > Open-Source Project", what do *I* do?). > > Reading down the thread, it was suggested to only branch when the > feature set is entirely known. While I'm in favor of late branching, > the nature of the Android ecosystem so far has been that multiple > releases routinely get worked on in parallel, which requires some > pretty early branching. At the same time, the feature set is known > very late, because some features get cut off late in the game > (typically because there's no time to complete them, because they > don't work as well as expected or because they're plagued with to many > bugs to fix in time). The way to only make code drops that match a > release feature set reasonably well is to only make code drops very > late in the process (in the last few weeks of multi-month development > cycles), which for all practical purposes boils down to making one > code drop when the release is completed - that would isolate the > Android Open-Source Project from the issue of managing expectations of > non-engineer people while continuing to not involve anyone else from > Google (and especially PR). > > JBQ > > On Mon, Jul 27, 2009 at 12:26 AM, Tom Gibara<[email protected]> wrote: >> Sorry if this sounds a bit grumpy (I've been up since 3am) but: >> 1) How is this different from what one might sensibly expect as a >> developer? I appreciate that not everyone is, but... >> 2) Importantly, how is this different from the process that occurred with >> cupcake? Most people labouring under these confusions have probably already >> seen cupcake come and go and... >> 3) Why are the Google engineers who spend their valuable time explaining >> these things being harangued about this? >> Unfortunately I don't have any suggestions about how to tackle this wave of >> misinformation that threatens to sweep over every Android release, as it >> seems to be baked into the 'social web'. >> Tom. >> >> 2009/7/27 Al Sutton <[email protected]> >>> >>> I've been having some twitter exchanges with JBQ and reading around the >>> various articles and I think I understand what donut is so I'm throwing it >>> out to the list so we can clear anything up. >>> >>> There is not one Donut but two. (Mmmmm... Donuts) >>> >>> One is the codename for the next release (i.e. donut release), One is the >>> branch in the git repo (i.e. donut tree). The feature set and version number >>> for the donut release has not been fixed. The features in the donut tree and >>> candidates for the donut release but are not guaranteed to be part of the >>> donut release. >>> >>> As for a donut release version number, JBQ seems to think that "System V" >>> is unlikely but anything is possible :). >>> >>> So; If you're using one of the donut sdks from the open source build you >>> are using the donut tree and so it has candidate features, you are not using >>> the donut release (because the shape and sprinkles for donut release have >>> not been finalise), so some features may not make the cut. >>> >>> The other thing to remember is that OEMs and carriers get their hand in so >>> even if a feature in donut tree does make it into donut release the OEM or >>> carrier may remove it before consumers get a chance to take a bite. >>> >>> Does anyone think this isn't right? >>> >>> Al. >>> >>> P.S. As I understand things Romains' comment about "donut is not 2.0" >>> should be read as "At the point in time when the comment was made donut tree >>> does not contain just contain features for a donut release, and 2.0 has not >>> been decided upon as the version number for the donut release. In the future >>> the donut release may be given the 2.0 version number, but that has not been >>> decided upon so *at this point in time* donut is not 2.0". >>> -- >>> >>> * Written an Android App? - List it at http://andappstore.com/ * >>> >>> ====== >>> Funky Android Limited is registered in England & Wales with the >>> company number 6741909. The registered head office is Kemp House, >>> 152-160 City Road, London, EC1V 2NX, UK. >>> >>> The views expressed in this email are those of the author and not >>> necessarily those of Funky Android Limited, it's associates, or it's >>> subsidiaries. >>> >>> >>> >>> >> >> >> > >> > > > > -- > Jean-Baptiste M. "JBQ" Queru > Software Engineer, Android Open-Source Project, Google. > > Questions sent directly to me that have no reason for being private > will likely get ignored or forwarded to a public forum with no further > warning. > > > > > > -- Jean-Baptiste M. "JBQ" Queru Software Engineer, Android Open-Source Project, Google. Questions sent directly to me that have no reason for being private will likely get ignored or forwarded to a public forum with no further warning. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
