[inline] On Fri, Apr 24, 2009 at 10:55 AM, Mark Murphy <[email protected]> wrote: > > This isn't so much an open source thing. Any product with an SDK would > run into this issue with what amounts to an API regression.
That's true indeed. Typically, though, a non-open project with an API might not quite be able to get the same level of community involvement in the API design as a sufficiently open open-source one. Luckily, the work that was done for the 1.5 SDK to support virtual devices will open more options to allow developers to play around with new system images without having to download an entirely new SDK (kudos to the devtools team for implementing it). > Is there a standard convention for docs/index.html holding this sort of > stuff for different components? > > If not, does anyone have a list of links to these pages? There's no standard yet that I know of. I put my doc in the source tree because I feel that's the most natural place for it, and because I wanted it to be visible outside of Google (even though it's incomplete and outdated). From that point, docs/index.html felt like the most natural filename. It'd be good for someone to build a list of all such documentation in the source tree, establish a pattern, and make things fit into that pattern. Putting stubs for the projects that don't have any documentation wouldn't hurt either. Ideally, such a list of links would be stored in the source tree itself, to keep the source tree somewhat self-contained. Bonus points for making it work both when browsed through gitweb and when stored locally in a checked-out tree (make sure that the file is at the root of the source tree). > For example, for all I know, there was some list squirreled away > somewhere that the public *could* have watched for debate on this topic. > Or, maybe the debate was all in the middle of some Gerrit thingy. Or it > was all done on IRC, or at a picnic lunch held in the shadow of a very > large droid in Mountain View. Google has a strong culture of face-to-face discussions, which tends to clash with the needs of an open-source community as it's private by nature - so the picnic explanation is sadly probably the one closest to reality (except that it probably happened in Dianne's office, which happens to have a direct view over said large droid). > I am less concerned about the specifics of Settings.Secure than I am the > timing and process by which we in the community find out about such > changes, and having the opportunity to participate in such changes to at > least some degree. Yup. I still believe that solving the transparency on the open-source side of Android is the shortest way toward solving the transparency on the SDK side, and I'd rather spend my efforts there (this is where the resource shortages come into play - I'd rather solve each problem once, even if that involves changing the order in which we solve them). > Yeah, yeah, yeah -- nag, nag, nag... ;-) You asked for it ;-) JBQ -- Jean-Baptiste M. "JBQ" Queru Android Engineer, 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 -~----------~----~----~----~------~----~------~--~---
