incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: PPMC guidance on new committers
Date Thu, 31 May 2007 21:42:20 GMT
As this seems to be an evolving Best Practice, I don't know that when
started a vote recently on two new committers for CXF that all of this was
apparent to me at the time. The current documentation at least
http://incubator.apache.org/guides/ppmc.html seems to indicate that we just
need a net positive of IPMC votes ("If the vote is positive...") and doesn't
seem to explicitly require a private vote*.

The current state of those votes are that we received 15 +1s for each
person, but none of the votes were from PMC members. I'm hoping that someone
can help me clarify what we should do next then. Specifically:
1. Do we need just a net positive of IPMC votes? Or 3 IPMC +1s?
2. We voted on the public list (the two committers both had great
contributions and I have/had no reason to think anyone would be -1 on them)
- even if thats not necessarily the best practice according to this document
(which we can maybe discuss in another thread) - I'm wondering what we
should do now. Should I put the [vote] to private@incubator still with some
descriptions of the things each individual has contributed and why we feel
they deserve commits?
3. Just to ensure I'm straight here - whoever sends in the account request
MUST be an IPMC member, right?

I have already pinged our mentors on the private cxf list, but didn't
receive any more votes yet, so I'm hoping we can get some guidance about
what to do next.
Thanks,

- Dan

* We've certainly done just public votes before and our mentors seemed ok
with it.

On 5/31/07, Craig L Russell <Craig.Russell@sun.com> wrote:
>
> Here's what I'd like to do with the ppmc guide. Change:
> Voting in a new committer
>
> If a developer has contributed a significant number of high-quality
> patches, is interested in continuing the contribution, and has
> demonstrated the ability to work well with others under the Apache
> guidelines, the project might vote to grant that developer commit
> access. See the ASF How it Works document, which explains meritocracy
> and roles.
>
> Discussion of a potential new committer should take place on the
> podling project's private list; normally it would take place on a
> project's private list. After vetting the new candidate, the vote can
> be called on either one of the two places listed below (notice the
> balance between private and public lists):
>
> The podling's private list, with notice posted to the Incubator
> private list.
> The developer list, with notice posted to the Incubator general list.
> The practice of a private discussion followed by a public, pro-forma,
> vote is re-emerging as a Best Practice for ASF projects (see this
> comprehensive discussion about these practices).
>
> Only votes cast by Incubator PMC members are binding. If the vote is
> positive, and the contributor accepts the responsibility of a
> committer for the project, the contributor formally becomes an Apache
> committer. An Incubator PMC member should then follow the documented
> procedures to complete the process, and CC both the Incubator PMC and
> the PPMC when sending the necessary e-mails to root.
>
> Please direct the new committer to the Apache developer's pages, to
> the Apache Incubator site and to the Incubator Committers Guide for
> important additional information.
>
> to:
>
> Voting in a new committer
>
> If a developer has contributed a significant number of high-quality
> patches, is interested in continuing the contribution, and has
> demonstrated the ability to work well with others under the Apache
> guidelines, the project might vote to grant that developer commit
> access. See the ASF How it Works document, which explains meritocracy
> and roles.
>
> One of the PPMC members should lead the process of accepting a new
> committer. For the purposes of this document, the proposing PPMC
> member is referred to as the proposer, and the proposed committer is
> referred to as the nominee. Discussion of a nominee should take place
> on the podling project's private (PPMC) list [normally it would take
> place on a project's private list]. If there are any concerns raised
> during the discussion, these need to be resolved so that there is
> consensus among the PPMC members as to the suitability of the nominee
> for the project and for Apache. After vetting the nominee, the vote
> can be called on either one of the two places listed below (notice
> the balance between private and public lists):
>
> o The podling's private list, with notice posted to the Incubator
> private list. The notice is a separate email forwarding the vote
> email with a cover statement that this vote is underway on the
> podling's private list. This is a good approach if you are not sure
> of getting the required three +1 votes from incubator PMC members on
> the first vote. After completing the vote on the PPMC list, if there
> are not three +1 votes from incubator PMC members, the proposer
> should call a vote on the incubator PMC private list with a reference
> to the archived discussion and vote by the PPMC.
>
> o The podling's developer list, with notice posted to the Incubator
> general list. The notice is a separate email forwarding the vote
> email with a cover statement that this vote is underway on the
> podling's developer list. This is a good approach if you are sure of
> getting the required three +1 votes from incubator PMC members. It is
> embarrassing to have a public vote fail or take a very long time
> because not enough incubator PMC members vote and have to be
> solicited to vote for a committer.
> Only votes cast by Incubator PMC members are binding. If the vote is
> positive (three or more binding +1 votes and no binding -1 votes),
> the proposer offers committership to the nominee. If the nominee
> accepts the responsibility of a committer for the project, the
> nominee formally becomes an Apache committer. The proposer then asks
> an Incubator PMC member to follow the documented procedures to
> complete the process.
>
> If the nominee is already an Apache committer on another project, the
> proposer asks the incubator PMC chair to update the authorization
> file to include the nominee as a committer on the podling. If the
> nominee is not already an Apache committer, the incubator PMC member
> CC's both the Incubator PMC and the PPMC when sending the necessary e-
> mails to root. Normally, the incubator PMC member is a Mentor on the
> podling's PPMC but due to unavailability, the proposer can ask any
> incubator PMC member.
>
> The proposer then directs the new committer to the Apache developer's
> pages, to the Apache Incubator site, and to the Incubator Committers
> Guide for important additional information.
>
> Craig
>
>
> On May 30, 2007, at 3:37 PM, Jean T. Anderson wrote:
>
> > Craig L Russell wrote:
> >> Hi Jean,
> >>
> >> On May 30, 2007, at 8:11 AM, Jean T. Anderson wrote:
> >>
> >>> Craig L Russell wrote:
> >>>
> >>>> Hi Carl,
> >>>>
> >>>> On May 30, 2007, at 6:14 AM, Carl Trieloff wrote:
> >>>>
> >>>>> One more question on this topic as I have also seen differing
> >>>>> views
> >>>>> from different members of the Incubator PMC on:  "Who can and
> >>>>> who  can
> >>>>> not send the account setup mail to root?"
> >>>>>
> >>>>> Given each new committer vote will have 3 PMC votes, why does a
> >>>>> mentor have to send the account setup to root? Why can't the
> >>>>> mail  to
> >>>>> root just contain a link to the vote result with 3 PMC
> >>>>> members   on it
> >>>>> from the general list?
> >>>>
> >>>> This is a question that I believe only infrastructure can
> >>>> answer. The
> >>>> issue is that right now, "root" has to respond only to emails
> >>>> from  PMC
> >>>> chairs, and it's easy to verify that it's really the PMC chair
> >>>> sending
> >>>> the request.
> >>>
> >>> In the general PMC case, "root" responds to requests from PMC
> >>> members:
> >>> "The project PMC needs to send an email to root at apache.org
> >>> requesting
> >>> a new account to be created" [1]. It says "project PMC" not
> >>> "project PMC
> >>> chair".
> >>
> >> Thanks for the correction. I need to remind myself to read the entire
> >> documentation every time, and not rely on memory. ;-)
> >
> > I don't know of anyone who has committed all apache docs to memory
> > -- I
> > sure haven't. :-)  The only reason I'm attentive to this detail is
> > as a
> > pmc chair myself I don't want account requests to be held up just
> > because I don't happen to be around.
> >
> >>> But I think the issue is that PPMCs aren't real PMCs,
> >>
> >> Right.
> >>
> >>> so for the
> >>> Incubator the request should come from a mentor.
> >>
> >> I'd prefer to say that the request must come from an incubator pmc
> >> member.
> >
> > yes; I think what matters to root is that the request is made from
> > somebody formally on the PMC, which makes this somebody easily
> > verified
> > by checking
> > https://svn.apache.org/repos/private/committers/board/committee-
> > info.txt
> > . Just like most of us haven't committed all apache docs to memory,
> > root
> > won't have committed the list of who is on which PMC to memory. We
> > want
> > to make it easy for root to process that account request.
> >
> >  -jean
> >
> >
> >> But then the ppmc member who is managing the new committer
> >> process should ask an incubator pmc member to make the root request,
> >> and that incubator pmc member would naturally but not necessarily be
> >> one of the podling's mentors.
> >>
> >> Craig
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
>


-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message