JBQ, I set about to improve the ANT support for the Android SDK. At first I thought I could boot-strap it by injecting new application build system via the build.template in sdk-install/template but that would be problem prone due to the wide audience that the Andorid SDK has and the boot-strappign method I was using. Thus, I concluded that improve ANT support would be beter as a spearate project, AndCoooper @googlecode hosting.
While, I did indirectly get feedback from several at Google, no set of feedback was ever expliciting direct. So my question is how do I improve my communication techniques to get Google's more direct attention as I have several other 'conributions' already planned.?? Is it possible to start a mailing list android-opensoruce-contributions possibly for this purpose and woudl that address some of the other issues as well? Thanks Fred Grott http://mobilebytes.wordpress.com On Mon, Jul 27, 2009 at 12:54 PM, Jean-Baptiste Queru <[email protected]>wrote: > > [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 -~----------~----~----~----~------~----~------~--~---
