*I agree* On Mon, Jul 27, 2009 at 9:49 AM, Jean-Baptiste Queru <[email protected]>wrote:
> > 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 -~----------~----~----~----~------~----~------~--~---
