[replying to my own post as it's otherwise gonna be hard to reply to every bit individually]
>how can we make it possible for non-Google developers >to make useful contributions to a branch if the open source >repo may spend 80% of the time being out of date?" As I see it, the best way to make contributions practical is for contributors to communicate clearly, extensively and early about their planned contributions, in order to be able to get feedback from Google about whether it's reasonable to contribute in a specific area of the code. In a nutshell, if you compensate for Google's communication flaws with the exact opposite behavior, you make it possible for someone to have access to all the relevant information and to make an informed decision. Instead of having the information and decision happen in the open like it would for the more transparent Open-Source projects, that work would take place behind Google's closed doors in our case, but it can be made to happen. That's the kind of reason why I've been trying to clean up and tighten the android-platform list, and that's why I'll continue policing it to try to make it as efficient a forum as possible to have such communication. That's also why I'm going to try to keep the master branch as up-to-date as I possibly can (within the limits of what gets pushed out, of course). >If Google wants them to have more >accurate information, Google needs to supply it. >From where I sit, I don't have a feeling that Google wants have more highly-visible official communication about Android, and more specifically about its Open-Source aspects. I've got to play with the cards I'm given instead of constantly hoping for a better hand. Even if there was a push for more communication, we're a very long way from having quick-response reactive communication about non-events on a week-end. >Google's getting into several super-high-profile open source projects I think that we should avoid making generic statements. Different projects target different ecosystems, which each have different players, different constraints, different partners, different users, different delivery models. >here are some basic ideas that occur to me One of the big work items indeed is to document a realistic source code management, branching and release process (one that actually exists and will be practical to stick to) and to set expectations accordingly. I'm trying to do that as I make progress toward a sensible process. At the moment such information still only lives on the android-platform mailing list, but as things crystallize I'll be placing it on the source.android.com site. There was a period of time when a lot of uncertainty caused us to be wishy-washy about many aspects of the Open-Source project while we were figuring out how we could actually get work done, and we've now gained enough experience to understand the constraints and the problems they cause, and to implement and document solutions. >roadmaps are generally kept secret for a couple of reasons There are plenty of reasons. Some of those reasons are similar to what you've mentioned. Another big reason is predictability: roadmaps change very quickly, and publishing them would cause people to make product plans based on roadmaps, only to see those plans torn apart when the roadmap changes (i.e. because the schedule changes, or because a critical feature for their plans gets removed). Sorry I can't give more details on that subject, that is not my area of expertise or authority. >there's a defect / enhancement reporting database While I've had to neglect the database for a few months in order to focus my efforts on other areas, I'm very much planning to continue using it, to catch up with the backlog, and to make it more useful. The current state of disrepair is caused by the lingering consequences of a lack of resources, not by a conscious strategic decision. JBQ PS: No offense taken, this is a very interesting discussion. On Mon, Jul 27, 2009 at 7: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. > -- 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 -~----------~----~----~----~------~----~------~--~---
