The list you're looking for is android-platform, which is the primary list dedicated to discussing open-source contributions. Over time, if the volume of open-source activity picks up, we might spin off some lists dedicated to specific areas of the system.
We're still facing a low signal-to-noise ratio there as the list is overwhelmed by people who should be asking their questions in android-developers or android-porting. As a result many of the Google engineers have left that list (or decided not to join) as working their way through off-topic threads takes too much time. I've been hoping to clean things up a bit, but we're not quite "there" yet, and I'm still looking for good ways to keep the group tightly on-topic without resorting to full moderation (which takes a lot of time) and without having to ban off-topic members. Two rules of thumb to get some attention on android-platform: -make it clear that you intend to actually contribute. -use a clear subject line, and start with a short but precise description of what you're trying to accomplish. What you just wrote about your work on ant pretty much fits the bill. Sadly at this point, there's still a high risk that a good post in android-platform would be glossed over. We don't intend to ignore good posts, but with all the noise it tends to happen quite a lot. Be patient, and send a brief ping after a few days if you don't see any response. JBQ On Wed, Jul 29, 2009 at 6:03 AM, Fred Grott<[email protected]> wrote: > 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. >> >> > > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
