Although I my questions were mostly rhetorical, I'm glad you answered them. Your detailed response has convinced me that the problem cannot be remedied by changing the source management process. I'm not certain whether there is a strategic approach that Google can apply across its open source projects, as Mark is suggesting, but here are some basic ideas that occur to me...
1) educating the active android development community about the release process and encouraging them to jump onto threads where the mistakes are being reported and correct them 2) establishing a document, one which has the blessing of senior staff, that's published on the android website; it would detail the approach to branching, drops etc. and the philosophy behind it 3) using the blog, or some other higher profile channel to round-up gossip and squash the inaccuracies (1) has the advantage of employing the time of people outside the core Android engineering team once the process is understood (this thread is clearly a helpful first stage), but I think it suffers from a lack of authority - it's one poster's word against another. (2) is probably the least work over the span of the project (in the expectation that Android has a long and glorious future), but hoping that people read it might be optimistic. It might be useful for linking-to in (1). (3) requires vigilance (ie. time) and I get a sinking feeling that any rumour which isn't instantly quashed will simply be taken as truth - it's a game that probably can't be won by direct rebuttal (what happens when a rumour turns out to be true?). So perhaps the combination of (1) and (2), I have to admit though that I even have to exert myself to read the threads where these misunderstandings accumulate; I'd personally struggle to find the will to keep posting corrections. Tom 2009/7/27 Jean-Baptiste Queru <[email protected]> > > 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 -~----------~----~----~----~------~----~------~--~---
