indeed, its either feature freeze or not release. IMHO that's a law of nature in IT every coder will learn once in his life. most of the times the hard way. (and it even rhymes ;) )
as for "leading android distro" currently that depends on how you define leading. if by "leading distro" you mean pre-installed on devices available in the TelCo Shop around the corner, no way. if you mean leading as "used by everyone who knows how to plug in a usb cable and read a certain website", that wouldn't be the first time, at least for anything htc related. the bacon Mark sees flying by might well have xda-developers painted on his rear wings. reflashing your android handset seems to be an astonishingly common place procedure these days. somehow android feels a bit like unbuntu in case of distro remixing to me. which is good. On Aug 12, 2:42 pm, Mark Murphy <[email protected]> wrote: > Al Sutton wrote: > > Switch b.android.com to Grid view, then change the Rows setting from > > none to "Stars", then click update. > > Hey, that's pretty slick. > > So, getting back to 6th-starred complaint: > > > I would have to say given that the 6th most starred issue in the > > Google Android's bug database had a perfectly working patch submitted > > from the community and it's been stated that it won't possibly be > > included even in eclair, Android isn't what most of us think of when > > we think of an open source project. > > Android isn't what you may think of in terms of an open source project, > but this hopefully isn't the reason. > > All open source projects bigger than breadbox have a point of feature > freeze, heading to a release. This appears to be even more prevalent > among open source operating systems. > > Android exacerbates this situation in two ways: > > 1. It is aimed pretty much exclusively at consumer electronics. Note my > use of "aimed" -- garden-variety PCs might *run* Android, but that's not > the *aim*. AFAICT, consumer electronics has a longer freeze period, > simply for manufacturing reasons. Any time you switch from bits to > atoms, things slow down. I know of Android handsets, not yet released, > that froze for manufacturing a couple of months ago. > > 2. The fact that we find out about the timetables on freezes after the > fact and via comments attached to one issue out of a couple thousand > doesn't exactly help the whole transparency thing. > > The patch in question was submitted two weeks ago. Either Android > donut/eclair was frozen at that point, or Jeff Sharkey (who people on > that issue seem to not realize *is* a Googler) wasn't able to find > somebody with the time to do all of the security checks before the > freeze came into place. As they say, shit happens. > > This is not significantly different than somebody proposing a new > package be added to Ubuntu Karmic after their freeze, except that the > freeze period is longer, indeterminate in length, and obscurely noted. > > Also, note that the underlying issue (FLAC support) might be solved by > another means, as Mr. Nelissen notes in the one Gerrit entry: > > https://review.source.android.com/#change,10910 > > > I just hope the attitude of "stop asking for something and submit a > > patch" will stop. Patch or no, it doesn't matter. There's no community > > involvement at the platform level. > > That's a fair assessment. Much of the infrastructure is in place (e.g., > Gerrit). However, as with any other open source project, > community-contributed patches only get integrated in the master repo if > one of the following is true: > > 1. It scratches an itch of a core contributor, who then takes it upon > herself to do what's needed to incorporate the patch (testing, security > checks, etc). > > 2. There are core contributors whose mission is simply to process > community contributions, or at least will take the time to process > community contributions even if that is not their sole responsibility. > > Right now, Android appears to lack #2, and #1 is a hit-or-miss > proposition. The answer eventually needs to be #2, but that requires > management buy-in, staffing increases (or roadmap curtailment to free up > staff time), etc. > > > I think it's only a matter of time as Google ignores the Apps on SD > > card feature until a different Android repository becomes the leading > > Android distribution. > > This is theoretically possible. I suspect I will see a winged side of > bacon fly by my window first, though. > > If you're talking about a partial fork -- more community contributions > plus porting all the enhancements made to the original Android -- that's > a huge chunk of work, requiring a huge chunk of developers. If you're > talking about a total fork, the forked project will wind up ahead of > Android in some areas (reflecting the itches of the fork founders) and > behind on others (where Android continues engineering work but its > capabilities are not ported). > > And, in either scenario, the project either needs device manufacturers > to start using the fork *or* continued good luck in rooting/flashing > alternative firmware onto existing Android devices. Otherwise, it's a > fork with no point. > > -- > Mark Murphy (a Commons > Guy)http://commonsware.com|http://twitter.com/commonsguy > > Android 1.5 Programming Books:http://commonsware.com/books.html --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
