Alright, Greg, I think I understand how Subversion's model is different, which is that the PMC members are all full committers. However, I still think that the model proposed here is purely organizational (how the PMC and committers organize themselves), and in no way changes peoples' ownership or rights. Certainly the reason I proposed it was organizational, to make sure patches get seen by the right people. I believe that every PMC member still has the same responsibility for two reasons:
1) The PMC is actually what selects the maintainers, so basically this mechanism is a way for the PMC to make sure certain people review each patch. 2) Code changes are all still made by consensus, where any individual has veto power over the code. The maintainer model mentioned here is only meant to make sure that the "experts" in an area get to see each patch *before* it is merged, and choose whether to exercise their veto power. Let me give a simple example, which is a patch to the Spark core public API. Say I'm a maintainer in this API. Without the maintainer model, the decision on the patch would be made as follows: - Any committer could review the patch and merge it - At any point during this process, I (as the main expert on this) could come in and -1 it, or give feedback - In addition, any other committer beyond me is allowed to -1 this patch With the maintainer model, the process is as follows: - Any committer could review the patch and merge it, but they would need to forward it to me (or another core API maintainer) to make sure we also approve - At any point during this process, I could come in and -1 it, or give feedback - In addition, any other committer beyond me is still allowed to -1 this patch The only change in this model is that committers are responsible to forward patches in these areas to certain other committers. If every committer had perfect oversight of the project, they could have also seen every patch to their component on their own, but this list ensures that they see it even if they somehow overlooked it. It's true that technically this model might "gate" development in the sense of adding some latency, but it doesn't "gate" it any more than consensus as a whole does, where any committer (not even PMC member) can -1 any code change. In fact I believe this will speed development by motivating the maintainers to be active in reviewing their areas and by reducing the chance that mistakes happen that require a revert. I apologize if this wasn't clear in any way, but I do think it's pretty clear in the original wording of the proposal. The sign-off by a maintainer is simply an extra step in the merge process, it does *not* mean that other committers can't -1 a patch, or that the maintainers get to review all patches, or that they somehow have more "ownership" of the component (since they already had the ability to -1). I also wanted to clarify another thing -- it seems there is a misunderstanding that only PMC members can be maintainers, but this was not the point; the PMC *assigns* maintainers but they can do it out of the whole committer pool (and if we move to separating the PMC from the committers, I fully expect some non-PMC committers to be made maintainers). I hope this clarifies where we're coming from, and why we believe that this still conforms fully with the spirit of Apache (collaborative, open development that anyone can participate in, and meritocracy for project governance). There were some comments made about the maintainers being only some kind of list of people without a requirement to review stuff, but as you can see it's the requirement to review that is the main reason I'm proposing this, to ensure we have an automated process for patches to certain components to be seen. If it helps we may be able to change the wording to something like "it is every committer's responsibility to forward patches for a maintained component to that component's maintainer", or something like that, instead of using "sign off". If we don't do this, I'd actually be against any measure that lists some component "maintainers" without them having a specific responsibility. Apache is not a place for people to gain kudos by having fancier titles given on a website, it's a place for building great communities and software. Matei > On Nov 6, 2014, at 9:27 PM, Greg Stein <gst...@gmail.com> wrote: > > On Thu, Nov 6, 2014 at 7:28 PM, Sandy Ryza <sandy.r...@cloudera.com> wrote: > >> It looks like the difference between the proposed Spark model and the >> CloudStack / SVN model is: >> * In the former, maintainers / partial committers are a way of >> centralizing oversight over particular components among committers >> * In the latter, maintainers / partial committers are a way of giving >> non-committers some power to make changes >> > > I can't speak for CloudStack, but for Subversion: yes, you're exactly > right, Sandy. > > We use the "partial committer" role as a way to bring in new committers. > "Great idea, go work >there<, and have fun". Any PMC member can give a > single +1, and that new (partial) committer gets and account/access, and is > off and running. We don't even ask for a PMC vote (though, we almost always > have a brief discussion). > > The "svnrdump" tool was written by a *Git* Google Summer of Code student. > He wanted a quick way to get a Subversion dumpfile from a remote > repository, in order to drop that into Git. We gave him commit access > directly into trunk/svnrdump, and he wrote the tool. Technically, he could > commit anywhere in our tree, but we just asked him not to, without a +1 > from a PMC member. > > Partial committers are a way to *include* people into the [coding] > community. And hopefully, over time, they grow into something more. > > "Maintainers" are a way (IMO) to *exclude* people from certain commit > activity. (or more precisely: limit/restrict, rather than exclude) > > You can see why it concerns me :-) > > Cheers, > -g --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
