> 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.
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.