[epp-dev] EPP Policy on committers and package maintainers?

[David M Williams <david_williams@xxxxxxxxxx>]

Since I said I would, I have written up a draft of a proposed EPP policy at

http://wiki.eclipse.org/EPP/EPP_Committer_and_Maintainer_Policy

I'm sure wording could be improved. But, I will let Markus take it from here, decide tweaks/improvements, from himself or others ... and leave it to him, as Project Lead, to work out "review and approval" with Technology PMC.

But, since I know the Technology PMC obviously follows this list :) I will make one small suggestion if it is helpful: Instead of tweaking the overall general policy to try and fit all cases (such as have an or clause with "closely related project") another approach might be to simply say "... this is the policy, unless a sub-project has their own documented policy, that has been reviewed and approved by the PMC". That'd seem to be easiest, most flexible, and leave final governance in the hands of the projects.

Hope this helps,



Steffen Pingel ---11/15/2011 09:46:50 AM---The proposal sounds good to me. There should be an easy way for committers from existing projects to

From: Steffen Pingel <steffen.pingel@xxxxxxxxxxx>
To: Eclipse Packaging Project <epp-dev@xxxxxxxxxxx>,
Date: 11/15/2011 09:46 AM
Subject: Re: [epp-dev] [technology-pmc] EPP Policy on committers and package maintainers?
Sent by: epp-dev-bounces@xxxxxxxxxxx

---

The proposal sounds good to me. There should be an easy way for
committers from existing projects to create new packages or update
existing EPP packages, e.g. by changing which components are included
in a package.

I agree with Doug that EPP and Orbit are not projects in the
traditional sense of the EDP and hence it makes sense to tailor the
project rules according to the special needs of EPP and Orbit.

Steffen


On Mon, Nov 14, 2011 at 3:24 PM, Schaefer, Doug
<Doug.Schaefer@xxxxxxxxxxxxx> wrote:
> No objections. In fact, I don’t think EPP or Orbit should be “projects”.
> They aren’t projects in the traditional sense. The only thing they inherit
> is a Unix group on the Eclipse servers to control access. We need to make
> sure these are properly managed, maybe by the Planning Council, to ensure
> Eclipse “product” gets out the door.
>
>
>
> Doug.
>
>
>
> From: epp-dev-bounces@xxxxxxxxxxx [mailto:epp-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Markus Knauer
> Sent: Monday, November 14, 2011 9:19 AM
> To: Eclipse Packaging Project
> Subject: Re: [epp-dev] [technology-pmc] EPP Policy on committers and package
> maintainers?
>
>
>
> This discussion developed into a discussion of the Technology PMC very
> fast... maybe too fast, because first I'd like to get more opinions from the
> existing committers on the EPP project. As soon as we are happy with it, I
> can try to make that happen together with the Technology PMC. They raised
> some valid points but on the other hand they seem to understand that EPP has
> different requirements for EPP committer elections.
>
> Are there any objections, suggestions, concerns to the initial draft that
> has been sent by David?
>
> Thanks,
>
> Markus
>
>
> 2011/11/8 Wayne Beaton <wayne@xxxxxxxxxxx>
>
> Another option is to change the Technology PMC charter.
>
> It's been needing an update for a few years anyway. This might be a good
> opportunity.
>
> Wayne
>
> On 11/08/2011 01:20 PM, Eric Rizzo wrote:
>
> 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.
>
> Eric
>
>
> 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
>
> epp-dev@xxxxxxxxxxx
>
> https://dev.eclipse.org/mailman/listinfo/epp-dev
>
>
>
> _______________________________________________
>
> epp-dev mailing list
>
> epp-dev@xxxxxxxxxxx
>
> https://dev.eclipse.org/mailman/listinfo/epp-dev
>
>
>
> --
>
> Wayne Beaton
>
> The Eclipse Foundation
>
> Twitter: @waynebeaton
>
> _______________________________________________
> technology-pmc mailing list
> technology-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/technology-pmc
>
>
> --
>
>
> ###
> EclipseSource Group
> Telefon: +49 721 664733-0 (GMT +2)
> Telefax: +49 721 66473329
>
> http://eclipsesource.com
>
>
>
> Innoopract Informationssysteme GmbH
> Lammstrasse 21, 76133 Karlsruhe Germany
> General Manager: Jochen Krause
> Registered Office: Karlsruhe, Commercial Register Mannheim HRB 107883
>
>
>
> _______________________________________________
> epp-dev mailing list
> epp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/epp-dev
>
>



-- 
Steffen Pingel
Senior Software Developer, Eclipse Mylyn
Mylyn Tasks Lead
http://tasktop.com
_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epp-dev