[ I'm going to try and pull a couple thread directions into this one, to avoid explosion :-) ]
On Thu, Nov 6, 2014 at 6:44 PM, Corey Nolet <cjno...@gmail.com> wrote: Note: I'm going to use "you" generically; I understand you [Corey] are not a PMC member, at this time. +1 (non-binding) [for original process proposal] > > Greg, the first time I've seen the word "ownership" on this thread is in > your message. The first time the word "lead" has appeared in this thread is > in your message as well. I don't think that was the intent. The PMC and > Committers have a > The word "ownership" is there, but with a different term. If you are a PMC member, and *cannot* alter a line of code without another's consent, then you don't "own" that code. Your ownership is subservient to another. You are not a *peer*, but a second-class citizen at this point. The term "maintainer" in this context is being used as a word for "lead". The maintainers are a *gate* for any change. That is not consensus. The proposal attempts to soften that, and turn it into an oligarchy of several maintainers. But the simple fact is that you have "some" with the ability to set direction, and those who do not. They are called "leaders" in most contexts, but however you want to slice it... the dynamic creates people with unequal commit ability. But as the PMC member you *are* responsible for it. That is the very basic definition of being a PMC member. You are responsible for "all things Spark". responsibility to the community to make sure that their patches are being > reviewed and committed. I don't see in Apache's recommended bylaws anywhere > that says establishing responsibility on paper for specific areas cannot be > taken on by different members of the PMC. What's been proposed looks, to > me, to be an empirical process and it looks like it has pretty much a > consensus from the side able to give binding votes. I don't at all this > model establishes any form of ownership over anything. I also don't see in > the process proposal where it mentions that nobody other than the persons > responsible for a module can review or commit code. > "where each patch to that component needs to get sign-off from at least one of its maintainers" That establishes two types of PMC members: those who require sign-off, and those who don't. Apache is intended to be a group of peers, none "more equal" than others. That said, we *do* recognize various levels of merit. This is where you see differences between committers, their range of access, and PMC members. But when you hit the *PMC member* role, then you are talking about a legal construct established by the Foundation. You move outside of community norms, and into how the umbrella of the Foundation operates. PMC members are individually responsible for all of the code under their purview, which is then at the direction of the Foundation itself. I'll skip that conversation, and leave it with the simple phrase: as a PMC member, you're responsible for the whole codebase. So following from that, anything that *restricts* your ability to work on that code, is a problem. In fact, I'll go as far as to say that since Apache is a meritocracy, the > people who have been aligned to the responsibilities probably were aligned > based on some sort of meric, correct? Perhaps we could dig in and find out > for sure... I'm still getting familiar with the Spark community myself. > Once you are a PMC member, then there is no difference in your merit. Merit ends. You're a PMC member, and that is all there is to it. Just because Jane commits 1000 times per month, makes her no better than John who commits 10/month. They are peers on the PMC and have equal rights and responsibility to the codebase. Historically, some PMCs have attempted to create variant levels within the PMC, or create different groups and rights, or different partitions over the code, and ... again, historically: it has failed. This is why Apache stresses consensus. The failure modes are crazy and numerous when moving away from that, into silos. >... On Thu, Nov 6, 2014 at 6:49 PM, Matei Zaharia <matei.zaha...@gmail.com> wrote: > So I don't understand, Greg, are the partial committers committers, or are > they not? Spark also has a PMC, but our PMC currently consists of all > committers (we decided not to have a differentiation when we left the > incubator). I see the Subversion partial committers listed as "committers" > on https://people.apache.org/committers-by-project.html#subversion, so I > assume they are committers. As far as I can see, CloudStack is similar. > PMC members are responsible for the code. They provide the oversight, direction, and management. (they're also responsible for the community, but that distinction isn't relevant in this contrasting example) Committers can make changes to the code, with the acknowledgement/agreement/direction of the PMC. When these groups are equal, like Spark, then things are pretty simple. But many communities in Apache define them as disparate. Committers may work on the code (a single area, or all of it), but don't have any direct input into its direction (ie. they're not on the PMC). Within Subversion, we give people commit rights to areas, and let them go wild. But they aren't part of the *whole* project's direction. Maybe just the SWIG bindings, or a migration tool, or a supplemental administrative tool. These are "partial committers", in Subversion's parlance. PMC members, on the other hand, are known historically as "full committers" and have rights over the whole codebase. There are no partitions. There are no component maintainers. Many projects at Apache provide whole-project commit access to people, but don't give them PMC rights. I find that strange, but it is quite common. The trust level is "code" rather than "direction". Subversion trusts people to limited areas, or to the whole project, and (thus) to the project's direction. ... Within this context of those who are responsible and involved with the project, I find it very disconcerting to partition things and tell people "you cannot make any change [even though you're on the PMC, and responsible for it] unless John says it is okay." Historically, Apache allowed fine-grained access control lists over who-could-change-what. Most of those have been removed, as we learned how dangerous they were to a community. How they set up cliques, and leads, and killed the peer relationships. As we've reviewed the relationships and oversight needs, to create a proper legal umbrella for all of our committers, the relationship of PMC members to its codebase has become much more clear. Unfortunately, much of this is historical knowledge, rather than written down. But writing it down makes it sounds like "rules", and proscriptions just never seem to work out right. It is a very hard problem, to share what works (or not) across the communities here at the Foundation. Cheers, -g
