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. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
