| |||||||||||||
No Mir by default in Ubuntu 13.10No Mir by default in Ubuntu 13.10Posted Oct 6, 2013 13:04 UTC (Sun) by krake (subscriber, #55996)In reply to: No Mir by default in Ubuntu 13.10 by khim Parent article: No Mir by default in Ubuntu 13.10
> GPE, OPIE, Enlightenment and many, many others.
Ah, good to know. Didn't know about the first two and I thought Enlightenment was a desktop software project.
> Very few reached the stage where you can actually use them on the real hardware
I am not sure I can follow here. Either they shipped and failed or they were simply not used. Failure implies trying.
> These are developed by “community” nowadays, too.
Maybe, didn't followed them too closely. Doesn't change the fact that they failed while not being community developed.
There is no correlation and certainly no causation between single vendor vs. multivendor developed product and market success.
What we can probably correlate is knowledge about number of prototype iterations with development process transparency.
(Log in to post comments)
No Mir by default in Ubuntu 13.10 Posted Oct 6, 2013 13:51 UTC (Sun) by khim (subscriber, #9252) [Link] I am not sure I can follow here. Either they shipped and failed or they were simply not used. Failure implies trying. Of course they have tried! They have some code, bunch of repos, even some demos. Best case scenario: they managed to run their stuff on a couple of old smartphone models (usually with bunch of hardware non-functional). OpenMoko is in this camp, the only thing which places it in their own category is the fact that it had software developed and actually created specifically for OpenMoko. Maybe, didn't followed them too closely. Doesn't change the fact that they failed while not being community developed. Well, if “community” is so important then what can't it make these projects success? Are projects which were adopted by community are somehow more problematic then projects developed by “community” from the start? What we can probably correlate is knowledge about number of prototype iterations with development process transparency. Hmm... So by now we know that opaque approach succeeds from time to time (even most iPhone suppliers had no idea that Apple does iPhone, Android developed Gerrit to make sure different developers can't see each other work yet still can develop common components, etc), while transparent approach fails (all “transparent” efforts are faileres. What does it say about “community” chances?
No Mir by default in Ubuntu 13.10 Posted Oct 6, 2013 14:20 UTC (Sun) by robclark (subscriber, #74945) [Link]
> Android developed Gerrit to make sure different developers can't see each other work yet still can develop common components
a bit off topic, but that would explain why I find gerrit so aggravating to use. Is that really true? Do you have a reference for that?
-----
back on the main topic.. I think the short answer is success or failure of a phone ecosystem has more to do with other factors than development model. But the fact that there are so few successes makes it difficult to draw any sort of conclusion.
No Mir by default in Ubuntu 13.10 Posted Oct 6, 2013 14:45 UTC (Sun) by khim (subscriber, #9252) [Link] What kind of “reference” do you need??? It's not a secret that enforceable access control was the reason for the Gerrit creation. Of course later it have gotten other properties, too, but initially it was just a “Rietvield with access control”. Heck, it's in description of the project background: Gerrit Code Review started as a simple set of patches to Rietveld, and was originally built to service AOSP. This quickly turned into a fork as we added access control features that Guido van Rossum did not want to see complicating the Rietveld code base.
No Mir by default in Ubuntu 13.10 Posted Oct 6, 2013 15:31 UTC (Sun) by robclark (subscriber, #74945) [Link]
> What kind of “reference” do you need??? It's not a secret that enforceable access control was the reason for the Gerrit creation. Of course later it have gotten other properties, too, but initially it was just a “Rietvield with access control”. Heck, it's in description of the project background: Gerrit Code Review started as a simple set of patches to Rietveld, and was originally built to service AOSP. This quickly turned into a fork as we added access control features that Guido van Rossum did not want to see complicating the Rietveld code base.
well, write-access control to prevent a developer from 'git push origin bonghits' is different from read-access, ie "developers can't see each other work". I was curious if read-access was actually a motivation as you at least seem to have implied. I didn't get this impression from either the wikipedia article or the 'project background' link.
one of my long standing complaints about the gerrit workflow (vs, send-patches-to-public-list approach, possibly augmented w/ patchwork) is that by default only the people you choose to review some patch(s) get notified. Vs. everyone seeing the patches and having a chance to review/comment.
No Mir by default in Ubuntu 13.10 Posted Oct 6, 2013 16:08 UTC (Sun) by khim (subscriber, #9252) [Link] well, write-access control to prevent a developer from 'git push origin bonghits' is different from read-access, ie "developers can't see each other work".Well, yeah. One is relevant to Rietveld, another is not relevant. I didn't get this impression from either the wikipedia article or the 'project background' link.Really? Please read it again. This quickly turned into a fork as we added access control features that Guido van Rossum did not want to see complicating the Rietveld code base. Then again. …access control features … Rietveld … code base. Got that? NOOO? I'll explain. Just what is Rietveld? It's collaborative code review tool. It can not read code from subversion or git (this is work of depot_tools), it can not commit code to the repo (this is work of commit queue), it's strictly and specifically review tool. Heck it's not even involved in ownership decisions—this is work for the presubmit scripts. Any changes which are complicating the Rietveld code base by necessity must affect patch review process—because Rietveld does not do anything else. Just what kind access control for patch review process can you imagine which does not affect patches viewability status? No, really? You may forbid certain users from adding the comments, but this change is pretty localized: you only need to check these things when new comments are added. You may add OWNERS, but this change does not affect Rietvield at all (it's enforced by presubmit scripts and commit queue). The only kind of change which may significantly perturb Rietvield's codebase is pervasive access control which determines who and when can watch patches which are in process of review. This will be invasive: this will mean that you need huge amount of checks spread over the codebase. All the information needed is there (and always was there), you just refused to connect the dots. one of my long standing complaints about the gerrit workflow (vs, send-patches-to-public-list approach, possibly augmented w/ patchwork) is that by default only the people you choose to review some patch(s) get notified. That's the whole point of gerrit! It's raison d’être! It's designed to facilitate parallel development of “open source” Android's code and vendor's proprietary “secret sauce” in parallel thus such decision makes perfect sense. Vs. everyone seeing the patches and having a chance to review/comment. Oh yeah. Imagine that. What SAMSUNG will do if patches needed to support their next innovative “air scrolling” will be seen by HTC or SONY? This will be huge brawl. Not pretty at all. This is what gerrit is dealing with: companies who actively try to destroy each other—yet are forced to cooperate. “Everyone seeing the patches and having a chance to review/comment” does not work for that.
No Mir by default in Ubuntu 13.10 Posted Oct 6, 2013 18:42 UTC (Sun) by robclark (subscriber, #74945) [Link]
> All the information needed is there (and always was there), you just refused to connect the dots.
Well, I guess I'm just not reading between the lines as hard as you are. I was looking for something a bit more concrete and a bit less conspiracy-theory.
All the same, my opinion remains the same: it isn't really a terribly good process tool for open source projects.
|
|||||||||||||