6 ms·
This just isn't true. I know for a fact JBQ has reviewed patches (and gotten relevant engineers to review things) that have made it into AOSP. The Android team
by durin42 15y ago
This just isn't true. I know for a fact JBQ has reviewed patches (and gotten relevant engineers to review things) that have made it into AOSP. The Android team does pre-push code review using Gerrit, and they often lack the personnel to review every change that comes in. As a result, patches sometimes (perhaps often?) wither on the vine before anyone can code review them.
Also: many potential contributors are scared off by the contributor license agreement required by AOSP. Patch contributions without the CLA can't even be reviewed.
As for not releasing honeycomb, look at releasing the kludged code from their perspective. They probably didn't want phones released from HC that wasn't ready for phone use, thus giving them a bad name when awful "Android Honeycomb Phones" hit the market.
- drzaiusapelord 15y agoExactly. Honeycomb was something of a stopgap to catch up to iPad while Google went for its unified phone/tab ICS OS. Considering all the 1.6/2.1 tablets that were released this year that were just horrible, I can see why google went this route. The industry was fucking up tablets pretty badly and I can't imagine AOpen or Archos or whomever having access to a half-cooked Honeycomb source and pushing out yet another shitty product. Instead we have gems like the Transformer, Galaxy Tab, Xoom, etc. Seems to me that google made the right move. Soon they'll all have access to ICS anyway. Lets see how badly these other companies fuck that up with their crapware, questionable UI changes, and cheesy hardware (I believe Archos or some other company is still selling resistive screens). Even if they do, we already have an established set of decent tablet products.
- mdwrigh2 15y agoI'd also point out that basically all tool development is done in the open in AOSP. As you pointed out, it's usually just a matter of finding the people necessary to do code reviews.
- cube13 15y ago>As for not releasing honeycomb, look at releasing the kludged code from their perspective. They probably didn't want phones released from HC that wasn't ready for phone use, thus giving them a bad name when awful "Android Honeycomb Phones" hit the market. Wasn't Honeycomb supposed to be a tablet-only OS? In which case, Google could have removed all cellular voice functionality, stated in the readme and release notes that this is intended for non-cellular phone devices only, and released it to the wild. Heck, they also could have refused to grant any usage of the Android trademarks to any manufacturer that used 3.1 source in a phone.
- yardie 15y agoThey could have done that but chances are a few of the less reputable OEMs would have ported code from Froyo or GB to get the dialer working again. The open nature of it means there is no restriction that could not be unrestricted. But in all honesty HC was a rush job (as was most of the hardware) to keep Android in the game against Apple. I'm really looking forward to it getting "there". With 2x the resources (CPU and RAM) of an iPad it should absolutely kill it, but when the applications hesitate for a split-second I really have to contemplate what the hell is going on?
- cube13 15y ago>They could have done that but chances are a few of the less reputable OEMs would have ported code from Froyo or GB to get the dialer working again. The open nature of it means there is no restriction that could not be unrestricted. Unfortunately, this is probably the biggest mistake that Google has made with Android. Google could have gone the route that the Mozilla foundation has with Firefox, where Mozilla does not allow modified Firefox source versions to use any of Mozilla's Firefox-related trademarks without their consent(http://www.mozilla.org/foundation/trademarks/policy.html http://www.mozilla.org/foundation/trademarks/policy.html). If one does wish to use the Firefox source in an official way, Mozilla has a "Powered by Mozilla" mark that they grant out for people that use the source. Google did not put such a policy in place with Android, which really limits their power with respect to "rogue" OEMs. Since they aren't charging for use of the OS, it's It has also led to the current issue that a lot of people have with pre-installed crapware or UIs. Ideally, I think that Google should have created a "Powered by Android" mark that they could grant to anyone that follows certain restrictions, like full comparability with the Android App store, the ability to root the phone, multitouch, etc. That would help them to protect their brand, especially in this case, because it would allow Google to enforce any potential issues like trying to shoehorn a 7" tablet UI/OS onto a 3.5" phone. Also, like Firefox, it would not stop guys like Cyanogen, because they could still use some other public mark.
- gergles 15y agoThey do have that, it's "with Google". Android phones that follow Google's platform guidelines can put a "with Google" logo on the device, otherwise they cannot.
- zobzu 15y agoto be precise, contributing means giving your copyright away to Google. It means all you're doing belongs to Google, not to the community, or yourself. Oddly it puts people off from contributing patches. Oddly! I'm all for freely contributing to projects, but I will never assign my copyright to a corporation. A not-for-profit at least, but corporation, come on.
- magicalist 15y agoIf we're actually being precise, you grant them an irrevocable license to your code, which is not at all the same thing: http://source.android.com/source/cla-individual.html http://source.android.com/source/cla-individual.html eg "Except for the license granted herein to the Project Leads and recipients of software distributed by the Project Leads, You reserve all right, title, and interest in and to Your Contributions." > I'm all for freely contributing to projects, but I will never assign my copyright to a corporation. A not-for-profit at least, but corporation, come on. The Mozilla committer's agreement, for instance, isn't that different in practice. You agree to specific licenses for your contribution (various shades of copyleft, MPL, GPL and LGPL) -- which amounts to anyone using that code being granted an irrevocable license -- but you retain copyright. http://www.mozilla.org/hacking/committer/committers-agreement.pdf http://www.mozilla.org/hacking/committer/committers-agreemen...
- durin42 15y agoThere's a HUGE difference between copyright assignment (required by FSF!) and a license agreement (Google, Apache, Mozilla, many others). The former means you are giving away ownership to your IP, which is what you describe. The latter only means that the project can relicense or similar (which is very important if there's a bug in a license, for example). You retain copyright to any contributions made under a CLA. It's a big difference. I don't see anything wrong with CLAs, and there are (according to some more versed in IP than I) some really good reasons to never accept patches without CLAs, especially when you're a potential high-profile lawsuit target.