[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [epp-dev] EPP Policy on committers and package maintainers?

I'm not an EPP committer or package maintainer, just an interested party and member of the Technology PMC. I think this idea has a lot of merit, but one thing that stands out to me is that the policy would be in direct contradiction with the Technology Project's policy on committer election (http://wiki.eclipse.org/Technology#Committer_Elections)

One solution top that dilemma would be to move EPP out from under the Technology umbrella; one could even make a case that it doesn't really belong there anymore, as part of the original Technology Project charter was that the sub-projects had a finite lifespan, but EPP is an ongoing effort. Unfortunately, I don't know under what other top-level project EPP would fit; the only ones that I can think of as even potential candidates would be Eclipse Project or Tools Project. But I'm not really sure about either of those.

Sorry I don't have any more concrete ideas than that; I'm copying the Technology PMC on this message in the hopes that some of my committee-mates will have some input.


On 11/8/11 12:26 PM, David M Williams wrote:

    Last year, all of us package maintainers became committers on EPP, by virtue of the fact we were package maintainers. While there is not a lot of development, per se, in EPP, nor committing required, I know some of us have added/removed a few things to our packages based on this committership.

    So, now, as time has passed, the question comes to mind about a) how to "transfer" package maintainer responsibility to someone else, and b) how to elect new committers to EPP. Seems we should have an established "project policy". How about if we combine the two?

    Markus and I have discussed a little, and we thought it time to raise this on epp-dev list, to see if any other committers had opinions or points of view that differed from ours. We were thinking that our policy in EPP be similar to how committership in Orbit is handled. In Orbit, if someone is a committer on another Eclipse project, and they state they are interested in contributing some packages to Orbit, that suffices for them to be nominated and voted-in as a committer and maintain what ever packages their project needs. This differs from most other projects where, for good reason, a person must have a history of contributions to that specific project, not just Eclipse in general. The Orbit model seems to fit EPP too, if some agrees to maintain a package (either a new package, or transfer "ownership"), and they are a committer in another Eclipse project, it seems reasonable they would not have to have any direct EPP contribution history. I guess the reasons to vote "no" (-1) would be something like "no, I am the current maintainer and I do not agree to this! :) ... or some other fairly large issue. Normally people do not vote "0" in Orbit, but but vote "+1" if basic criteria are met, to be welcoming and supportive of new people coming in. Normally, we'd propose, unless a committer explicitly "resigns" there would be no automatic removal of a committer just because package responsibility is transferred, except eventually the usual "inactive" reasons would apply ... if someone is no longer responsible for maintaining a package and has not been active on mailing lists, etc., for a period of 6 months or so, the Project Lead can remove them via Eclipse Portal for "inactivity". And, of course, committers should explicitly resign, if appropriate, such as they are changing responsibilities and know they have no interest or time to be involved. (In Orbit, someone may contribute a bundle, and then do nothing else for years, but they stay a committer ... but every now and then, I have removed people from the Orbit committer list, if they are no longer are listed as the contact for maintaining a bundle, and, obviously, do not otherwise participate in Orbit discussions, etc.)

    Does anyone object to us using the "Orbit model" of committership? Any other suggestions on how to transfer package "ownership"? If there are no objections and no alternatives are forthcoming, I'll write up this policy on our EPP Wiki in about a week and ask Markus to also discuss with (or send note to) Technology PMC, to make sure they would not find controversy with this policy (or, what ever policy we end up with, from this discussion).

    So, EPP Committers, let us know, here on epp-dev, what you think of this proposed policy ... especially if you think further discussion of alternatives is needed.

epp-dev mailing list