You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Joe Schaefer <jo...@yahoo.com> on 2010/08/11 19:45:48 UTC
an experiment
So. Following some advice given to me by Sam Ruby,
I'd like to start experimenting with different organizational
and procedural approaches to the projects I participate in
here. What I want to do is to see how far I can push
the envelope on the whole notion of empowerment and
self-governance in an incubating project, following the
lessons I've learned from httpd's treatment of the subprojects
it happens to be responsible for.
The first idea should be fairly straightforward: that for
the projects I participate in (so far thrift and sis), that
the IPMC delegates to the PPMC the decision-making process
for voting in new committers: basically rolling back the clock
to May 1, 2007 on guides/ppmc.html.
The second idea is more controversial: to hold IPMC votes to
admit all significant committers to those projects to the IPMC
itself. The purpose of this concept is to allow those who
best know the codebase to provide IPMC oversight over it,
especially as it pertains to releases.
I welcome your comments, criticisms, and other feedback.
Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Christian Grobmeier <gr...@gmail.com>.
>> >> +1 to IPMC delegates to the PPMC the decision-making
>> >> process for voting in new committers (one question,
>> >> would they need an ACK from IPMC - similar to how PMC's
>> >> send a note to the board for an ACK for new pmc members)?
>> >
>> > That certainly sounds like a reasonable thing to do, sure.
+1
>> >> In the 2nd question, "significant committers", are we asking
>> >> mentors to identify such candidates for addition to IPMC,
>> >> especially release managers for example? if so, +1 for that
>> >> as well.
>>
>> I was also curious as to the mechanism for determining
>> "significance"--I would be satisfied with mentors'
>> recommendation as outlined by dims.
>
> By significant I mean active and clueful participants
> in the project.
>
>> I wonder if there should be some limit/function
>> to determine the number of non-Member representatives
>> a given podling may have on the IPMC.
>
> I don't care for artificial limits. Trust has a way
> of maintaining its own balance.
>
+1
Both ideas sound very good to me
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Matt Benson <gu...@gmail.com>
> To: general@incubator.apache.org
> Sent: Wed, August 11, 2010 5:19:53 PM
> Subject: Re: an experiment
>
>
> On Aug 11, 2010, at 4:14 PM, Joe Schaefer wrote:
>
> >
> >
> > ----- Original Message ----
> >
> >> From: Davanum Srinivas <da...@gmail.com>
> >> To: general@incubator.apache.org
> >> Sent: Wed, August 11, 2010 5:07:33 PM
> >> Subject: Re: an experiment
> >>
> >> +1 to IPMC delegates to the PPMC the decision-making
> >> process for voting in new committers (one question,
> >> would they need an ACK from IPMC - similar to how PMC's
> >> send a note to the board for an ACK for new pmc members)?
> >
> > That certainly sounds like a reasonable thing to do, sure.
> >
>
> +1
>
> >> In the 2nd question, "significant committers", are we asking
> >> mentors to identify such candidates for addition to IPMC,
> >> especially release managers for example? if so, +1 for that
> >> as well.
> >
>
> I was also curious as to the mechanism for determining
> "significance"--I would be satisfied with mentors'
> recommendation as outlined by dims.
By significant I mean active and clueful participants
in the project. IOW people who have earned the trust of
the project mentors. It would be an evolving process
for a new project: at first nobody would meet that
description, but over time as the mentors got to know
the participants and see how they work, collaborate,
review, and critique releases, we'd gain their trust
and offer them up to an IPMC vote for inclusion.
> I wonder if there should be some limit/function
> to determine the number of non-Member representatives
> a given podling may have on the IPMC.
I don't care for artificial limits. Trust has a way
of maintaining its own balance.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Matt Benson <gu...@gmail.com>.
On Aug 11, 2010, at 4:14 PM, Joe Schaefer wrote:
>
>
> ----- Original Message ----
>
>> From: Davanum Srinivas <da...@gmail.com>
>> To: general@incubator.apache.org
>> Sent: Wed, August 11, 2010 5:07:33 PM
>> Subject: Re: an experiment
>>
>> +1 to IPMC delegates to the PPMC the decision-making
>> process for voting in new committers (one question,
>> would they need an ACK from IPMC - similar to how PMC's
>> send a note to the board for an ACK for new pmc members)?
>
> That certainly sounds like a reasonable thing to do, sure.
>
+1
>> In the 2nd question, "significant committers", are we asking
>> mentors to identify such candidates for addition to IPMC,
>> especially release managers for example? if so, +1 for that
>> as well.
>
I was also curious as to the mechanism for determining "significance"--I would be satisfied with mentors' recommendation as outlined by dims. I wonder if there should be some limit/function to determine the number of non-Member representatives a given podling may have on the IPMC.
-Matt
> Absolutely, especially RM's that have gotten into the habit
> of running RAT themselves.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Stefan Bodewig <bo...@apache.org>
> To: general@incubator.apache.org
> Sent: Thu, August 12, 2010 12:43:59 AM
> Subject: Re: an experiment
> There isn't anything that would stop a mentor from proposing a podling
> committer who is not an ASF member as an IPMC member today, is there?
> I'd expect you'd get the required votes for people who have been RMs or
> contributed "significantly" from enough other IPMC members.
Other than changing historical precedents that only supremely great
committers are admitted to the IPMC, no. I want us to evaluate these
folks based on their work in a single podling, not their cross-project
interests.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Stefan Bodewig <bo...@apache.org>.
On 2010-08-11, Joe Schaefer wrote:
> From: Davanum Srinivas <da...@gmail.com>
>> +1 to IPMC delegates to the PPMC the decision-making process for
>> voting in new committers (one question, would they need an ACK from
>> IPMC - similar to how PMC's send a note to the board for an ACK for
>> new pmc members)?
> That certainly sounds like a reasonable thing to do, sure.
+1
>> In the 2nd question, "significant committers", are we asking
>> mentors to identify such candidates for addition to IPMC,
>> especially release managers for example? if so, +1 for that
>> as well.
> Absolutely, especially RM's that have gotten into the habit
> of running RAT themselves.
There isn't anything that would stop a mentor from proposing a podling
committer who is not an ASF member as an IPMC member today, is there?
I'd expect you'd get the required votes for people who have been RMs or
contributed "significantly" from enough other IPMC members.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Davanum Srinivas <da...@gmail.com>
> To: general@incubator.apache.org
> Sent: Wed, August 11, 2010 5:07:33 PM
> Subject: Re: an experiment
>
> +1 to IPMC delegates to the PPMC the decision-making
> process for voting in new committers (one question,
> would they need an ACK from IPMC - similar to how PMC's
> send a note to the board for an ACK for new pmc members)?
That certainly sounds like a reasonable thing to do, sure.
> In the 2nd question, "significant committers", are we asking
> mentors to identify such candidates for addition to IPMC,
> especially release managers for example? if so, +1 for that
> as well.
Absolutely, especially RM's that have gotten into the habit
of running RAT themselves.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Davanum Srinivas <da...@gmail.com>.
+1 to IPMC delegates to the PPMC the decision-making process for voting in new committers (one question, would they need
an ACK from IPMC - similar to how PMC's send a note to the board for an ACK for new pmc members)?
In the 2nd question, "significant committers", are we asking mentors to identify such candidates for addition to IPMC,
especially release managers for example? if so, +1 for that as well.
thanks,
dims
On 08/11/2010 01:45 PM, Joe Schaefer wrote:
> So. Following some advice given to me by Sam Ruby,
> I'd like to start experimenting with different organizational
> and procedural approaches to the projects I participate in
> here. What I want to do is to see how far I can push
> the envelope on the whole notion of empowerment and
> self-governance in an incubating project, following the
> lessons I've learned from httpd's treatment of the subprojects
> it happens to be responsible for.
>
> The first idea should be fairly straightforward: that for
> the projects I participate in (so far thrift and sis), that
> the IPMC delegates to the PPMC the decision-making process
> for voting in new committers: basically rolling back the clock
> to May 1, 2007 on guides/ppmc.html.
>
> The second idea is more controversial: to hold IPMC votes to
> admit all significant committers to those projects to the IPMC
> itself. The purpose of this concept is to allow those who
> best know the codebase to provide IPMC oversight over it,
> especially as it pertains to releases.
>
> I welcome your comments, criticisms, and other feedback.
> Thanks.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Donald Woods <dw...@apache.org>.
On 8/11/10 5:30 PM, Davanum Srinivas wrote:
>
> On 08/11/2010 05:19 PM, Donald Woods wrote:
>>
>>
>> On 8/11/10 1:45 PM, Joe Schaefer wrote:
>>> So. Following some advice given to me by Sam Ruby,
>>> I'd like to start experimenting with different organizational
>>> and procedural approaches to the projects I participate in
>>> here. What I want to do is to see how far I can push
>>> the envelope on the whole notion of empowerment and
>>> self-governance in an incubating project, following the
>>> lessons I've learned from httpd's treatment of the subprojects
>>> it happens to be responsible for.
>>>
>>> The first idea should be fairly straightforward: that for
>>> the projects I participate in (so far thrift and sis), that
>>> the IPMC delegates to the PPMC the decision-making process
>>> for voting in new committers: basically rolling back the clock
>>> to May 1, 2007 on guides/ppmc.html.
>>
>> How about requiring at least one mentor on the vote, so there is still
>> some oversight?
>
> Having all mentors vote is good but not necessary...IMHO
>
>>>
>>> The second idea is more controversial: to hold IPMC votes to
>>> admit all significant committers to those projects to the IPMC
>>> itself. The purpose of this concept is to allow those who
>>> best know the codebase to provide IPMC oversight over it,
>>> especially as it pertains to releases.
>>
>> Would still like this to be an opt-in, where any existing PMC member
>> interested in helping with the Incubator could request membership and be
>> added after 72 hours (expanding ASF member rules to apply to all PMC
>> members.) For committers (non-PMC members), I'd want an existing IPMC
>> or PMC member nominate the person to the IPMC and require a 72hr lazy
>> consensus, since IPMC members are expected to mentor and teach new
>> podlings about the Apache way.
>
> By PMC you mean PPMC? i am confused.
Any PMC member of a TLP. The projects have obviously vetted their
skills and contributions before inviting to their PMC, so the barrier to
IPMC membership should be lower for them.
>
>>>
>>> I welcome your comments, criticisms, and other feedback.
>>> Thanks.
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Davanum Srinivas <da...@gmail.com>.
On 08/11/2010 05:19 PM, Donald Woods wrote:
>
>
> On 8/11/10 1:45 PM, Joe Schaefer wrote:
>> So. Following some advice given to me by Sam Ruby,
>> I'd like to start experimenting with different organizational
>> and procedural approaches to the projects I participate in
>> here. What I want to do is to see how far I can push
>> the envelope on the whole notion of empowerment and
>> self-governance in an incubating project, following the
>> lessons I've learned from httpd's treatment of the subprojects
>> it happens to be responsible for.
>>
>> The first idea should be fairly straightforward: that for
>> the projects I participate in (so far thrift and sis), that
>> the IPMC delegates to the PPMC the decision-making process
>> for voting in new committers: basically rolling back the clock
>> to May 1, 2007 on guides/ppmc.html.
>
> How about requiring at least one mentor on the vote, so there is still
> some oversight?
Having all mentors vote is good but not necessary...IMHO
>>
>> The second idea is more controversial: to hold IPMC votes to
>> admit all significant committers to those projects to the IPMC
>> itself. The purpose of this concept is to allow those who
>> best know the codebase to provide IPMC oversight over it,
>> especially as it pertains to releases.
>
> Would still like this to be an opt-in, where any existing PMC member
> interested in helping with the Incubator could request membership and be
> added after 72 hours (expanding ASF member rules to apply to all PMC
> members.) For committers (non-PMC members), I'd want an existing IPMC
> or PMC member nominate the person to the IPMC and require a 72hr lazy
> consensus, since IPMC members are expected to mentor and teach new
> podlings about the Apache way.
By PMC you mean PPMC? i am confused.
>>
>> I welcome your comments, criticisms, and other feedback.
>> Thanks.
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Donald Woods <dw...@apache.org>.
On 8/11/10 5:29 PM, Joe Schaefer wrote:
> ----- Original Message ----
>
>> From: Donald Woods <dw...@apache.org>
>> To: general@incubator.apache.org
>> Sent: Wed, August 11, 2010 5:19:03 PM
>> Subject: Re: an experiment
>>
>>
>>
>> On 8/11/10 1:45 PM, Joe Schaefer wrote:
>>> So. Following some advice given to me by Sam Ruby,
>>> I'd like to start experimenting with different organizational
>>> and procedural approaches to the projects I participate in
>>> here. What I want to do is to see how far I can push
>>> the envelope on the whole notion of empowerment and
>>> self-governance in an incubating project, following the
>>> lessons I've learned from httpd's treatment of the subprojects
>>> it happens to be responsible for.
>>>
>>> The first idea should be fairly straightforward: that for
>>> the projects I participate in (so far thrift and sis), that
>>> the IPMC delegates to the PPMC the decision-making process
>>> for voting in new committers: basically rolling back the clock
>>> to May 1, 2007 on guides/ppmc.html.
>>
>> How about requiring at least one mentor on the vote, so there is still
>> some oversight?
>
> I'm actually not in favor of that idea because relatively few
> mentors are active developers in their projects (I'm certainly
> in that category). Part of what I'm trying to teach is that
> self-governance requires active participants to be making the
> critical decisions.
>
> OTOH I would be perfectly OK with the idea that a mentor must
> file the account request, or more simply must submit an ACK request
> regarding the vote to either general@incubator or private@incubator.
>
Sounds like a good solution for accounts, but I'd still like to see at
least one mentor vote required on release artifacts, as the mentors
agreed to step up and guide/teach podlings about the Apache Way, which
includes using RAT and IANAL plugins to ensure license headers on the
code and license/notice/disclaimer artifacts in the released artifacts.
>>>
>>> The second idea is more controversial: to hold IPMC votes to
>>> admit all significant committers to those projects to the IPMC
>>> itself. The purpose of this concept is to allow those who
>>> best know the codebase to provide IPMC oversight over it,
>>> especially as it pertains to releases.
>>
>> Would still like this to be an opt-in, where any existing PMC member
>> interested in helping with the Incubator could request membership and be
>> added after 72 hours (expanding ASF member rules to apply to all PMC
>> members.)
>
> Are you referring to ASF members here? PMC members themselves who
> are not ASF members must be voted in by the IPMC to gain IPMC membership.
> ASF members interested in IPMC membership need only notify the chair
> of their intentions. I don't expect any of that to change with what
> I'm proposing.
>
>> For committers (non-PMC members), I'd want an existing IPMC
>> or PMC member nominate the person to the IPMC and require a 72hr lazy
>> consensus, since IPMC members are expected to mentor and teach new
>> podlings about the Apache way.
>
> I would expect a more formal process of consensus voting for IPMC
> membership in the case of a podling committer, ie 3 +1's and no
> vetoes. The vote would be held on private@incubator naturally.
>
Agree.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Joe Schaefer <jo...@yahoo.com>
> To: general@incubator.apache.org
> Sent: Wed, August 11, 2010 5:29:55 PM
> Subject: Re: an experiment
>
> ----- Original Message ----
>
> > From: Donald Woods <dw...@apache.org>
> > To: general@incubator.apache.org
> > Sent: Wed, August 11, 2010 5:19:03 PM
> > Subject: Re: an experiment
> > Would still like this to be an opt-in, where any existing PMC member
> > interested in helping with the Incubator could request membership and be
> > added after 72 hours (expanding ASF member rules to apply to all PMC
> > members.)
>
> Are you referring to ASF members here? PMC members themselves who
> are not ASF members must be voted in by the IPMC to gain IPMC membership.
> ASF members interested in IPMC membership need only notify the chair
> of their intentions. I don't expect any of that to change with what
> I'm proposing.
Oh I see what you're saying now. Expanding the opt-in rule from ASF members
to any PMC member is an interesting concept, but not part of what I was
planning to do.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: an experiment
Posted by "Noel J. Bergman" <no...@devtech.com>.
Joe Schaefer wrote:
> > How about requiring at least one mentor on the vote, so there is still
> > some oversight?
> I'm actually not in favor of that idea because relatively few
> mentors are active developers in their projects (I'm certainly
> in that category). Part of what I'm trying to teach is that
> self-governance requires active participants to be making the
> critical decisions.
They should be participating in the decisions, but the fact remains that
they are not PMC members, they are still a provisional community (by
definition of being in the Incubator), and the PMC cannot abandon its
mandated oversight.
The moral of the story is if you (generic, not Joe :-)) want to make
decisions, demonstrate that you are making them the ASF Way, and get to
graduation as soon as possible.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Donald Woods <dw...@apache.org>
> To: general@incubator.apache.org
> Sent: Wed, August 11, 2010 5:19:03 PM
> Subject: Re: an experiment
>
>
>
> On 8/11/10 1:45 PM, Joe Schaefer wrote:
> > So. Following some advice given to me by Sam Ruby,
> > I'd like to start experimenting with different organizational
> > and procedural approaches to the projects I participate in
> > here. What I want to do is to see how far I can push
> > the envelope on the whole notion of empowerment and
> > self-governance in an incubating project, following the
> > lessons I've learned from httpd's treatment of the subprojects
> > it happens to be responsible for.
> >
> > The first idea should be fairly straightforward: that for
> > the projects I participate in (so far thrift and sis), that
> > the IPMC delegates to the PPMC the decision-making process
> > for voting in new committers: basically rolling back the clock
> > to May 1, 2007 on guides/ppmc.html.
>
> How about requiring at least one mentor on the vote, so there is still
> some oversight?
I'm actually not in favor of that idea because relatively few
mentors are active developers in their projects (I'm certainly
in that category). Part of what I'm trying to teach is that
self-governance requires active participants to be making the
critical decisions.
OTOH I would be perfectly OK with the idea that a mentor must
file the account request, or more simply must submit an ACK request
regarding the vote to either general@incubator or private@incubator.
> >
> > The second idea is more controversial: to hold IPMC votes to
> > admit all significant committers to those projects to the IPMC
> > itself. The purpose of this concept is to allow those who
> > best know the codebase to provide IPMC oversight over it,
> > especially as it pertains to releases.
>
> Would still like this to be an opt-in, where any existing PMC member
> interested in helping with the Incubator could request membership and be
> added after 72 hours (expanding ASF member rules to apply to all PMC
> members.)
Are you referring to ASF members here? PMC members themselves who
are not ASF members must be voted in by the IPMC to gain IPMC membership.
ASF members interested in IPMC membership need only notify the chair
of their intentions. I don't expect any of that to change with what
I'm proposing.
> For committers (non-PMC members), I'd want an existing IPMC
> or PMC member nominate the person to the IPMC and require a 72hr lazy
> consensus, since IPMC members are expected to mentor and teach new
> podlings about the Apache way.
I would expect a more formal process of consensus voting for IPMC
membership in the case of a podling committer, ie 3 +1's and no
vetoes. The vote would be held on private@incubator naturally.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Donald Woods <dw...@apache.org>.
On 8/11/10 1:45 PM, Joe Schaefer wrote:
> So. Following some advice given to me by Sam Ruby,
> I'd like to start experimenting with different organizational
> and procedural approaches to the projects I participate in
> here. What I want to do is to see how far I can push
> the envelope on the whole notion of empowerment and
> self-governance in an incubating project, following the
> lessons I've learned from httpd's treatment of the subprojects
> it happens to be responsible for.
>
> The first idea should be fairly straightforward: that for
> the projects I participate in (so far thrift and sis), that
> the IPMC delegates to the PPMC the decision-making process
> for voting in new committers: basically rolling back the clock
> to May 1, 2007 on guides/ppmc.html.
How about requiring at least one mentor on the vote, so there is still
some oversight?
>
> The second idea is more controversial: to hold IPMC votes to
> admit all significant committers to those projects to the IPMC
> itself. The purpose of this concept is to allow those who
> best know the codebase to provide IPMC oversight over it,
> especially as it pertains to releases.
Would still like this to be an opt-in, where any existing PMC member
interested in helping with the Incubator could request membership and be
added after 72 hours (expanding ASF member rules to apply to all PMC
members.) For committers (non-PMC members), I'd want an existing IPMC
or PMC member nominate the person to the IPMC and require a 72hr lazy
consensus, since IPMC members are expected to mentor and teach new
podlings about the Apache way.
>
> I welcome your comments, criticisms, and other feedback.
> Thanks.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Craig L Russell <cr...@oracle.com>
> To: general@incubator.apache.org
> Sent: Thu, August 12, 2010 2:21:44 PM
> Subject: Re: an experiment
>
>
> On Aug 11, 2010, at 10:45 AM, Joe Schaefer wrote:
>
> > The first idea should be fairly straightforward: that for
> > the projects I participate in (so far thrift and sis), that
> > the IPMC delegates to the PPMC the decision-making process
> > for voting in new committers: basically rolling back the clock
> > to May 1, 2007 on guides/ppmc.html.
> >
> Before we set ourselves up for disappointment based on
> unrealistic expectations, this proposal is fairly modest.
> Here's the current process for getting new committers into an incubating
>project:
>
> 1. Identify candidates
> 2. Discuss candidates on podling-private
> 3. Agree that candidate should be a committer
> 4. Vote on podling-private
> 5. Wait for everyone's vote
> 6. Inform incubator PMC of results of vote
> 7. Vote in incubator PMC if not all three mentors have voted
> 8. Invite committer
> 9. Send ICLA
> 10. Wait for ICLA registration
> 11. Send root request for committer
> 12. Wait for root to create account
> 13. Update asf authorization file for new account
> 14. Done
>
> All this proposal does is to eliminate step 7 in the case where the Mentors
>are AWOL.
As Justin points out there is also a pre-notification step
in the current process that would also go away, but yes that
is the gist of it.
>
> That said, I support the idea behind this modest proposal,
> and just need to see the details (several modifications
> have been proposed). Infra also needs to support this
> proposal, as the main reason for item 7 is to get root to
> recognize that the incubator PMC has taken official action
> (three votes in favor of a new committer) which has been
> an infrastructure requirement (also part of the details).
As the infra person who has created each and every account
in this org over the past 4 years, I think I can safely
speak to infra's interest in this issue. root@ only looks
that the account request has been cc'd to all the proper
lists and expects those lists to ensure proper procedure
has been followed for the request. root@ maintains a few
days delay between receipt of an acct request and action
on it in order to allow for effective oversight.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Davanum Srinivas <da...@gmail.com>.
Fair enough :)
Sent from my iPhone
On Aug 12, 2010, at 3:10 PM, Craig L Russell
<cr...@oracle.com> wrote:
> Hi Dims,
>
> On Aug 12, 2010, at 12:05 PM, Davanum Srinivas wrote:
>
>> Craig,
>>
>> in my mind, it's not the number of steps that we eliminate, it's the
>> message that we send. Instead of saying you all are *under* the
>> microscope, we say that real quickly a few of you will become part of
>> the microscope and look in on not just yours but also other
>> podlings...my 2 cents.
>
> I think your comment is in regard to Joe's other proposal that all
> committers become part of the incubator PMC. I didn't address that
> proposal here.
>
> Craig
>
>>
>> thanks,
>> dims
>>
>> On Thu, Aug 12, 2010 at 2:21 PM, Craig L Russell
>> <cr...@oracle.com> wrote:
>>>
>>> On Aug 11, 2010, at 10:45 AM, Joe Schaefer wrote:
>>>
>>>> The first idea should be fairly straightforward: that for
>>>> the projects I participate in (so far thrift and sis), that
>>>> the IPMC delegates to the PPMC the decision-making process
>>>> for voting in new committers: basically rolling back the clock
>>>> to May 1, 2007 on guides/ppmc.html.
>>>>
>>> Before we set ourselves up for disappointment based on unrealistic
>>> expectations, this proposal is fairly modest. Here's the current
>>> process for
>>> getting new committers into an incubating project:
>>>
>>> 1. Identify candidates
>>> 2. Discuss candidates on podling-private
>>> 3. Agree that candidate should be a committer
>>> 4. Vote on podling-private
>>> 5. Wait for everyone's vote
>>> 6. Inform incubator PMC of results of vote
>>> 7. Vote in incubator PMC if not all three mentors have voted
>>> 8. Invite committer
>>> 9. Send ICLA
>>> 10. Wait for ICLA registration
>>> 11. Send root request for committer
>>> 12. Wait for root to create account
>>> 13. Update asf authorization file for new account
>>> 14. Done
>>>
>>> All this proposal does is to eliminate step 7 in the case where
>>> the Mentors
>>> are AWOL.
>>>
>>> That said, I support the idea behind this modest proposal, and
>>> just need to
>>> see the details (several modifications have been proposed). Infra
>>> also needs
>>> to support this proposal, as the main reason for item 7 is to get
>>> root to
>>> recognize that the incubator PMC has taken official action (three
>>> votes in
>>> favor of a new committer) which has been an infrastructure
>>> requirement (also
>>> part of the details).
>>>
>>> Craig
>>>
>>> Craig L Russell
>>> Architect, Oracle
>>> http://db.apache.org/jdo
>>> 408 276-5638 mailto:Craig.Russell@oracle.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>>
>>> ---
>>> ------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Davanum Srinivas :: http://davanum.wordpress.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
> Craig L Russell
> Architect, Oracle
> http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@oracle.com
> P.S. A good JDO? O, Gasp!
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Craig L Russell <cr...@oracle.com>.
Hi Dims,
On Aug 12, 2010, at 12:05 PM, Davanum Srinivas wrote:
> Craig,
>
> in my mind, it's not the number of steps that we eliminate, it's the
> message that we send. Instead of saying you all are *under* the
> microscope, we say that real quickly a few of you will become part of
> the microscope and look in on not just yours but also other
> podlings...my 2 cents.
I think your comment is in regard to Joe's other proposal that all
committers become part of the incubator PMC. I didn't address that
proposal here.
Craig
>
> thanks,
> dims
>
> On Thu, Aug 12, 2010 at 2:21 PM, Craig L Russell
> <cr...@oracle.com> wrote:
>>
>> On Aug 11, 2010, at 10:45 AM, Joe Schaefer wrote:
>>
>>> The first idea should be fairly straightforward: that for
>>> the projects I participate in (so far thrift and sis), that
>>> the IPMC delegates to the PPMC the decision-making process
>>> for voting in new committers: basically rolling back the clock
>>> to May 1, 2007 on guides/ppmc.html.
>>>
>> Before we set ourselves up for disappointment based on unrealistic
>> expectations, this proposal is fairly modest. Here's the current
>> process for
>> getting new committers into an incubating project:
>>
>> 1. Identify candidates
>> 2. Discuss candidates on podling-private
>> 3. Agree that candidate should be a committer
>> 4. Vote on podling-private
>> 5. Wait for everyone's vote
>> 6. Inform incubator PMC of results of vote
>> 7. Vote in incubator PMC if not all three mentors have voted
>> 8. Invite committer
>> 9. Send ICLA
>> 10. Wait for ICLA registration
>> 11. Send root request for committer
>> 12. Wait for root to create account
>> 13. Update asf authorization file for new account
>> 14. Done
>>
>> All this proposal does is to eliminate step 7 in the case where the
>> Mentors
>> are AWOL.
>>
>> That said, I support the idea behind this modest proposal, and just
>> need to
>> see the details (several modifications have been proposed). Infra
>> also needs
>> to support this proposal, as the main reason for item 7 is to get
>> root to
>> recognize that the incubator PMC has taken official action (three
>> votes in
>> favor of a new committer) which has been an infrastructure
>> requirement (also
>> part of the details).
>>
>> Craig
>>
>> Craig L Russell
>> Architect, Oracle
>> http://db.apache.org/jdo
>> 408 276-5638 mailto:Craig.Russell@oracle.com
>> P.S. A good JDO? O, Gasp!
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
>
>
> --
> Davanum Srinivas :: http://davanum.wordpress.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Craig L Russell
Architect, Oracle
http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@oracle.com
P.S. A good JDO? O, Gasp!
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Davanum Srinivas <da...@gmail.com>.
Craig,
in my mind, it's not the number of steps that we eliminate, it's the
message that we send. Instead of saying you all are *under* the
microscope, we say that real quickly a few of you will become part of
the microscope and look in on not just yours but also other
podlings...my 2 cents.
thanks,
dims
On Thu, Aug 12, 2010 at 2:21 PM, Craig L Russell
<cr...@oracle.com> wrote:
>
> On Aug 11, 2010, at 10:45 AM, Joe Schaefer wrote:
>
>> The first idea should be fairly straightforward: that for
>> the projects I participate in (so far thrift and sis), that
>> the IPMC delegates to the PPMC the decision-making process
>> for voting in new committers: basically rolling back the clock
>> to May 1, 2007 on guides/ppmc.html.
>>
> Before we set ourselves up for disappointment based on unrealistic
> expectations, this proposal is fairly modest. Here's the current process for
> getting new committers into an incubating project:
>
> 1. Identify candidates
> 2. Discuss candidates on podling-private
> 3. Agree that candidate should be a committer
> 4. Vote on podling-private
> 5. Wait for everyone's vote
> 6. Inform incubator PMC of results of vote
> 7. Vote in incubator PMC if not all three mentors have voted
> 8. Invite committer
> 9. Send ICLA
> 10. Wait for ICLA registration
> 11. Send root request for committer
> 12. Wait for root to create account
> 13. Update asf authorization file for new account
> 14. Done
>
> All this proposal does is to eliminate step 7 in the case where the Mentors
> are AWOL.
>
> That said, I support the idea behind this modest proposal, and just need to
> see the details (several modifications have been proposed). Infra also needs
> to support this proposal, as the main reason for item 7 is to get root to
> recognize that the incubator PMC has taken official action (three votes in
> favor of a new committer) which has been an infrastructure requirement (also
> part of the details).
>
> Craig
>
> Craig L Russell
> Architect, Oracle
> http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@oracle.com
> P.S. A good JDO? O, Gasp!
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Davanum Srinivas :: http://davanum.wordpress.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: an experiment
Posted by "Noel J. Bergman" <no...@devtech.com>.
Craig L Russell wrote:
> Here's the current process for getting new committers into an incubating
project:
> 1. Identify candidates
> 2. Discuss candidates on podling-private
> 3. Agree that candidate should be a committer
All PPMC functions; need no outside involvement.
> 4. Vote on podling-private
> 5. Wait for everyone's vote
> 6. Inform incubator PMC of results of vote
> 7. Vote in incubator PMC if not all three mentors have voted
Translation: vote and talley. How can we streamline this with oversight?
- Initiate vote on <podling>-private & concurrently notify PMC
- Tally votes (ping PMC if more votes are necessary)
- Post vote results to <podling>-private / cc: private@
I don't see anything to remove, and assuming that the podling has 3+ active
Mentors, the PMC is not a time block. But processing of the actual vote
*is* where the PMC exerts oversight.
> 8. Invite committer
> 9. Send ICLA
> 10. Wait for ICLA registration
> 11. Send root request for committer
> 12. Wait for root to create account
> 13. Update asf authorization file for new account
I don't see anything to remove from here, nor is there any PMC-specific
task.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Craig L Russell <cr...@oracle.com>.
On Aug 11, 2010, at 10:45 AM, Joe Schaefer wrote:
> The first idea should be fairly straightforward: that for
> the projects I participate in (so far thrift and sis), that
> the IPMC delegates to the PPMC the decision-making process
> for voting in new committers: basically rolling back the clock
> to May 1, 2007 on guides/ppmc.html.
>
Before we set ourselves up for disappointment based on unrealistic
expectations, this proposal is fairly modest. Here's the current
process for getting new committers into an incubating project:
1. Identify candidates
2. Discuss candidates on podling-private
3. Agree that candidate should be a committer
4. Vote on podling-private
5. Wait for everyone's vote
6. Inform incubator PMC of results of vote
7. Vote in incubator PMC if not all three mentors have voted
8. Invite committer
9. Send ICLA
10. Wait for ICLA registration
11. Send root request for committer
12. Wait for root to create account
13. Update asf authorization file for new account
14. Done
All this proposal does is to eliminate step 7 in the case where the
Mentors are AWOL.
That said, I support the idea behind this modest proposal, and just
need to see the details (several modifications have been proposed).
Infra also needs to support this proposal, as the main reason for item
7 is to get root to recognize that the incubator PMC has taken
official action (three votes in favor of a new committer) which has
been an infrastructure requirement (also part of the details).
Craig
Craig L Russell
Architect, Oracle
http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@oracle.com
P.S. A good JDO? O, Gasp!
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Aug 11, 2010 at 7:45 PM, Joe Schaefer <jo...@yahoo.com> wrote:
> ...The first idea should be fairly straightforward: that for
> the projects I participate in (so far thrift and sis), that
> the IPMC delegates to the PPMC the decision-making process
> for voting in new committers: basically rolling back the clock
> to May 1, 2007 on guides/ppmc.html....
+1, but I think we should require at least one +1 from a mentor in
those votes, to make sure mentors are following the action. And
mentors or IPMC members making the account requests.
>
> The second idea is more controversial: to hold IPMC votes to
> admit all significant committers to those projects to the IPMC
> itself. The purpose of this concept is to allow those who
> best know the codebase to provide IPMC oversight over it,
> especially as it pertains to releases....
Sounds good to me, having PPMC members participate in the IPMC helps
cross-pollination of ideas.
Here as well, I'd require the mentors to nominate those significant
committers, as another way of making sure mentors are involved in the
process.
-Bertrand (didn't read the whole thread yet - holidays ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Niclas Hedhman <ni...@hedhman.org>
> To: general@incubator.apache.org
> Sent: Thu, August 12, 2010 1:13:41 AM
> Subject: Re: an experiment
> Yes, definitely more controversial. Pros would include greater
> exposure to the Incubator noise, learning from others, becoming part
> of Apache for real. The main cons is that doesn't happen and instead
> we have podlings inadvertently becomes even more isolated islands, as
> they no longer required to get others involved at all.
>
> Let's try this with Thrift and Sis, as Thrift is always quoted as a
> troubled community, no releases and so forth. If it will work for that
> podling, I am convinced. If it doesn't work for either, then I think
> we need some other mechanism.
FWIW I also follow esme to a certain extent, so if these changes don't
produce negative results after a few months I'd probably want to include
them in the experiment as well.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thu, Aug 12, 2010 at 1:45 AM, Joe Schaefer <jo...@yahoo.com> wrote:
> The first idea should be fairly straightforward: that for
> the projects I participate in (so far thrift and sis), that
> the IPMC delegates to the PPMC the decision-making process
> for voting in new committers: basically rolling back the clock
> to May 1, 2007 on guides/ppmc.html.
Please refrain from that phrase; since it is debatable what was the
actual policy previously.
I am +1 to the suggestion that Thrift and Sis are empowered to be
self-governing in respect to committers. I am even positive to do this
across all podlings, if roo@ is ok with it.
> The second idea is more controversial: to hold IPMC votes to
> admit all significant committers to those projects to the IPMC
> itself. The purpose of this concept is to allow those who
> best know the codebase to provide IPMC oversight over it,
> especially as it pertains to releases.
Yes, definitely more controversial. Pros would include greater
exposure to the Incubator noise, learning from others, becoming part
of Apache for real. The main cons is that doesn't happen and instead
we have podlings inadvertently becomes even more isolated islands, as
they no longer required to get others involved at all.
Let's try this with Thrift and Sis, as Thrift is always quoted as a
troubled community, no releases and so forth. If it will work for that
podling, I am convinced. If it doesn't work for either, then I think
we need some other mechanism.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: ant elder <an...@gmail.com>
> To: general@incubator.apache.org
> Sent: Wed, August 11, 2010 6:16:16 PM
> Subject: Re: an experiment
>
> On Wed, Aug 11, 2010 at 6:45 PM, Joe Schaefer <jo...@yahoo.com> wrote:
>
>
> > The second idea is more controversial: to hold IPMC votes to
> > admit all significant committers to those projects to the IPMC
> > itself. The purpose of this concept is to allow those who
> > best know the codebase to provide IPMC oversight over it,
> > especially as it pertains to releases.
> >
>
> Without some more explanation I'm not that convinced about doing that.
> The main purpose of the IPMC is to vote on the graduation of
> poddlings, why should some random ASF poddling newbie get a binding
> vote on the graduation of _any_ poddling?
>
> I'm guessing the motivation for this proposal is not to give poddling
> committers binding votes on other poddling graduations but to give
> them binding votes on their own poddling activities, and that i agree
> with. The things they need binding votes on is their committer votes,
> ppmc votes (they already have that), and release votes - lets just
> give them those.
You do have a very good point, however my experience with being on
the httpd PMC as a subproject committer is that I will remain a
non-participant in the decision-making process of the projects I
don't work on. So what I'm saying is that the theoretical concern
that podling committers with IPMC membership will have the authority
to vote on the graduation of other projects (including their own I
suppose), in practice those privileges are not going to be exercised
for "social reasons".
The main problem here is in coming to terms with release voting,
because there are foundation-wide rules and policies that *every*
release must follow. I am not sure the IPMC can simply delegate
those decisions to the PPMC without tacit board approval of such
a policy.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Big +1 to all Greg's comments below. Let's just try it - I don't see a huge effort/loss ratio - I think we'd all be surprised at how well folks are at responding to requests if we just ask them to.
Cheers,
Chris
On 8/11/10 10:15 PM, "Greg Stein" <gs...@gmail.com> wrote:
On Wed, Aug 11, 2010 at 19:24, Joe Schaefer <jo...@yahoo.com> wrote:
>> From: Davanum Srinivas <da...@gmail.com>
>> To: general@incubator.apache.org
>> Sent: Wed, August 11, 2010 6:28:17 PM
>> Subject: Re: an experiment
>>
>> Ant,
>>
>> My personal opinion (and i am hoping!) was that such individuals
>> from ppmc's who end up in ipmc would help build bridges
>> between podlings and will help get lessons learned (when any ppmc
>> has issues/problems/roadblocks) back to their ppmc.
>> This is one area where i've seen people struggle, folks from
>> different projects learning the same lessons the hard way.
>
> Good point.
Yup. Goodness.
>> I am not too worried about "binding" vote one podling ppmc
>> member have over another podling's release. the "binding" is
>> for me a legal thing (as in we need 3 binding ipmc votes for a release).
>
> I think ant is more concerned about graduation votes. We
> could simply write a new rule that podling committers on
> the IPMC brought in through my initiative MUST ABSTAIN from
> graduation votes. I don't think the board would be the
> least bit upset if we did that.
Nah. Don't impose more rules.
In Subversion, we vote in committers and we tell them "only commit to
/some/path". And they do that. We don't need technical measures. We
simply *ask*.
Let new IPMC members know that they should be wary of voting on issues
outside of their "domain of expertise." If they *do* vote, then let
them. If they are out of line, then let them discuss why they
voted/thought that way. It can be a learning exercise. Maybe they'll
change their vote. If you find somebody that just never "gets it" and
is "obstructionist", *then* you can deal with it.
Be optimistic and give them rights. What is the true failure mode
here? What is the full exposure? Is it really a problem? Is it such a
problem that rules are required? [beyond simple social requests]
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: an experiment
Posted by Greg Stein <gs...@gmail.com>.
On Wed, Aug 11, 2010 at 19:24, Joe Schaefer <jo...@yahoo.com> wrote:
>> From: Davanum Srinivas <da...@gmail.com>
>> To: general@incubator.apache.org
>> Sent: Wed, August 11, 2010 6:28:17 PM
>> Subject: Re: an experiment
>>
>> Ant,
>>
>> My personal opinion (and i am hoping!) was that such individuals
>> from ppmc's who end up in ipmc would help build bridges
>> between podlings and will help get lessons learned (when any ppmc
>> has issues/problems/roadblocks) back to their ppmc.
>> This is one area where i've seen people struggle, folks from
>> different projects learning the same lessons the hard way.
>
> Good point.
Yup. Goodness.
>> I am not too worried about "binding" vote one podling ppmc
>> member have over another podling's release. the "binding" is
>> for me a legal thing (as in we need 3 binding ipmc votes for a release).
>
> I think ant is more concerned about graduation votes. We
> could simply write a new rule that podling committers on
> the IPMC brought in through my initiative MUST ABSTAIN from
> graduation votes. I don't think the board would be the
> least bit upset if we did that.
Nah. Don't impose more rules.
In Subversion, we vote in committers and we tell them "only commit to
/some/path". And they do that. We don't need technical measures. We
simply *ask*.
Let new IPMC members know that they should be wary of voting on issues
outside of their "domain of expertise." If they *do* vote, then let
them. If they are out of line, then let them discuss why they
voted/thought that way. It can be a learning exercise. Maybe they'll
change their vote. If you find somebody that just never "gets it" and
is "obstructionist", *then* you can deal with it.
Be optimistic and give them rights. What is the true failure mode
here? What is the full exposure? Is it really a problem? Is it such a
problem that rules are required? [beyond simple social requests]
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Davanum Srinivas <da...@gmail.com>
> To: general@incubator.apache.org
> Sent: Wed, August 11, 2010 8:07:50 PM
> Subject: Re: an experiment
>
> Joe,
>
> Can they not +1 it either? :) seriously, it would be a
> bit hard to track 2 levels of ipmc members
If we're concerned about tracking, we could simplify the
rule to say only ASF members on the IPMC may participate
in graduation voting. Otherwise publishing a list of
podling committers on the IPMC would probably be required,
which I'd like to avoid as well ;-).
>
> -- dims
>
>
>
> On 08/11/2010 07:24 PM, Joe Schaefer wrote:
> > ----- Original Message ----
> >
> >> From: Davanum Srinivas<da...@gmail.com>
> >> To: general@incubator.apache.org
> >> Sent: Wed, August 11, 2010 6:28:17 PM
> >> Subject: Re: an experiment
> >>
> >> Ant,
> >>
> >> My personal opinion (and i am hoping!) was that such individuals
> >> from ppmc's who end up in ipmc would help build bridges
> >> between podlings and will help get lessons learned (when any ppmc
> >> has issues/problems/roadblocks) back to their ppmc.
> >> This is one area where i've seen people struggle, folks from
> >> different projects learning the same lessons the hard way.
> >
> > Good point.
> >
> >> I am not too worried about "binding" vote one podling ppmc
> >> member have over another podling's release. the "binding" is
> >> for me a legal thing (as in we need 3 binding ipmc votes for a release).
> >
> > I think ant is more concerned about graduation votes. We
> > could simply write a new rule that podling committers on
> > the IPMC brought in through my initiative MUST ABSTAIN from
> > graduation votes. I don't think the board would be the
> > least bit upset if we did that.
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Davanum Srinivas <da...@gmail.com>.
Joe,
Can they not +1 it either? :) seriously, it would be a bit hard to track 2 levels of ipmc members
-- dims
On 08/11/2010 07:24 PM, Joe Schaefer wrote:
> ----- Original Message ----
>
>> From: Davanum Srinivas<da...@gmail.com>
>> To: general@incubator.apache.org
>> Sent: Wed, August 11, 2010 6:28:17 PM
>> Subject: Re: an experiment
>>
>> Ant,
>>
>> My personal opinion (and i am hoping!) was that such individuals
>> from ppmc's who end up in ipmc would help build bridges
>> between podlings and will help get lessons learned (when any ppmc
>> has issues/problems/roadblocks) back to their ppmc.
>> This is one area where i've seen people struggle, folks from
>> different projects learning the same lessons the hard way.
>
> Good point.
>
>> I am not too worried about "binding" vote one podling ppmc
>> member have over another podling's release. the "binding" is
>> for me a legal thing (as in we need 3 binding ipmc votes for a release).
>
> I think ant is more concerned about graduation votes. We
> could simply write a new rule that podling committers on
> the IPMC brought in through my initiative MUST ABSTAIN from
> graduation votes. I don't think the board would be the
> least bit upset if we did that.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Davanum Srinivas <da...@gmail.com>
> To: general@incubator.apache.org
> Sent: Wed, August 11, 2010 6:28:17 PM
> Subject: Re: an experiment
>
> Ant,
>
> My personal opinion (and i am hoping!) was that such individuals
> from ppmc's who end up in ipmc would help build bridges
> between podlings and will help get lessons learned (when any ppmc
> has issues/problems/roadblocks) back to their ppmc.
> This is one area where i've seen people struggle, folks from
> different projects learning the same lessons the hard way.
Good point.
> I am not too worried about "binding" vote one podling ppmc
> member have over another podling's release. the "binding" is
> for me a legal thing (as in we need 3 binding ipmc votes for a release).
I think ant is more concerned about graduation votes. We
could simply write a new rule that podling committers on
the IPMC brought in through my initiative MUST ABSTAIN from
graduation votes. I don't think the board would be the
least bit upset if we did that.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by ant elder <an...@gmail.com>.
On Wed, Aug 11, 2010 at 11:28 PM, Davanum Srinivas <da...@gmail.com> wrote:
> Ant,
>
> My personal opinion (and i am hoping!) was that such individuals from ppmc's
> who end up in ipmc would help build bridges between podlings and will help
> get lessons learned (when any ppmc has issues/problems/roadblocks) back to
> their ppmc.
Isn't that sort of thing exactly what hasn't happened in past projects
with sub projects and why these days sub projects often get moved out
to be TLPs? If a poddlings active committers warrent being on the IPMC
why not graduate the poddling or give the poddling its own PMC? It
would be good for poddlings to have more control over their own
activities like voting committers and releases and this would give
them that which is good so i guess I wouldn't stand in the way of
trying it, but doing it with this approach does feel like we'd just be
creating another great big umbrella project with all the issues that
has.
...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Davanum Srinivas <da...@gmail.com>.
Ant,
My personal opinion (and i am hoping!) was that such individuals from ppmc's who end up in ipmc would help build bridges
between podlings and will help get lessons learned (when any ppmc has issues/problems/roadblocks) back to their ppmc.
This is one area where i've seen people struggle, folks from different projects learning the same lessons the hard way.
I am not too worried about "binding" vote one podling ppmc member have over another podling's release. the "binding" is
for me a legal thing (as in we need 3 binding ipmc votes for a release).
-- dims
On 08/11/2010 06:16 PM, ant elder wrote:
> On Wed, Aug 11, 2010 at 6:45 PM, Joe Schaefer<jo...@yahoo.com> wrote:
>
>
>> The second idea is more controversial: to hold IPMC votes to
>> admit all significant committers to those projects to the IPMC
>> itself. The purpose of this concept is to allow those who
>> best know the codebase to provide IPMC oversight over it,
>> especially as it pertains to releases.
>>
>
> Without some more explanation I'm not that convinced about doing that.
> The main purpose of the IPMC is to vote on the graduation of
> poddlings, why should some random ASF poddling newbie get a binding
> vote on the graduation of _any_ poddling?
>
> I'm guessing the motivation for this proposal is not to give poddling
> committers binding votes on other poddling graduations but to give
> them binding votes on their own poddling activities, and that i agree
> with. The things they need binding votes on is their committer votes,
> ppmc votes (they already have that), and release votes - lets just
> give them those.
>
> ...ant
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by ant elder <an...@gmail.com>.
On Wed, Aug 11, 2010 at 6:45 PM, Joe Schaefer <jo...@yahoo.com> wrote:
> The second idea is more controversial: to hold IPMC votes to
> admit all significant committers to those projects to the IPMC
> itself. The purpose of this concept is to allow those who
> best know the codebase to provide IPMC oversight over it,
> especially as it pertains to releases.
>
Without some more explanation I'm not that convinced about doing that.
The main purpose of the IPMC is to vote on the graduation of
poddlings, why should some random ASF poddling newbie get a binding
vote on the graduation of _any_ poddling?
I'm guessing the motivation for this proposal is not to give poddling
committers binding votes on other poddling graduations but to give
them binding votes on their own poddling activities, and that i agree
with. The things they need binding votes on is their committer votes,
ppmc votes (they already have that), and release votes - lets just
give them those.
...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Greg Reddin <gr...@gmail.com>.
On Wed, Aug 11, 2010 at 12:45 PM, Joe Schaefer <jo...@yahoo.com> wrote:
> The first idea should be fairly straightforward: that for
> the projects I participate in (so far thrift and sis), that
> the IPMC delegates to the PPMC the decision-making process
> for voting in new committers: basically rolling back the clock
> to May 1, 2007 on guides/ppmc.html.
>
> The second idea is more controversial: to hold IPMC votes to
> admit all significant committers to those projects to the IPMC
> itself. The purpose of this concept is to allow those who
> best know the codebase to provide IPMC oversight over it,
> especially as it pertains to releases.
Just to pile on, as a member of the SIS podling, I'm +1 to both of these ideas.
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Wed, Aug 11, 2010 at 10:49 AM, Mattmann, Chris A (388J)
<ch...@jpl.nasa.gov> wrote:
> Hi Joe,
>
>> The first idea should be fairly straightforward: that for
>> the projects I participate in (so far thrift and sis), that
>> the IPMC delegates to the PPMC the decision-making process
>> for voting in new committers: basically rolling back the clock
>> to May 1, 2007 on guides/ppmc.html.
>
> +1 from me, and I'd like to OODT to that experimental list as well :) It
> would probably make sense for Lucy too, but we're in our nascence there (not
> that it should matter).
+1 to trying this out in OODT as well. =P
As far as the ACK process, I'd be okay with an after-the-vote ACK (a
la what the Board does with PMC members), but the goofy "pre-vote" ACK
is what got us in OODT-land taken out to the woodshed by the IPMC. --
justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: an experiment
Posted by "Noel J. Bergman" <no...@devtech.com>.
Joe Schaefer wrote:
> I'm challenging the idea that allowing subprojects to vote in new
committers all
> by themselves is somehow taboo in this org
I understand. I am specifically raising that issue with the Board in this
month's report.
> > Giving them commit access has been deemed an action requiring a vote of
the
> > PMC.
> Are you referring to a board resolution, or just some passed down wisdom
> that you have received?
I'm not aware of a resolution. Let's see what comes back from the Board.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Noel J. Bergman <no...@devtech.com>
> To: general@incubator.apache.org
> Sent: Mon, August 16, 2010 2:02:15 PM
> Subject: RE: an experiment
>
> Joe Schaefer wrote:
>
> > Are you trying to tell me that both jakarta and httpd have been in
> violation
> > of Apache bylaws all these years?
>
> As as matter of fact, YES.
>
> I can't speak for the HTTP Server situation, but in the case of Jakarta,
> that was one of the reasons for breaking it up, along with pushing to make
> every committer a PMC member. Before that, Jakarta had allowed projects to
> vote their own releases outside of the PMC, and that finally raised some big
> red flags. I remember that clearly, as I suspect would Serge and Danny.
Let's not conflate release votes with committer votes. I'm not challenging
IPMC process on releases at this point. I'm challenging the idea that allowing
subprojects to vote in new committers all by themselves is somehow taboo
in this org, because that does not match my experience with httpd, and
it certainly wasn't how jakarta operated prior to the restructuring.
> > The fact that committers have no legal standing in this org means there is
> > no reason a "decision" made about them needs formal approval by a PMC.
> > Your reading of the corporate structure of this org is needlessly formal.
>
> Giving them commit access has been deemed an action requiring a vote of the
> PMC. And sometimes the job description of a PMC Chair is
Are you referring to a board resolution, or just some passed down wisdom
that you have received?
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: an experiment
Posted by "Noel J. Bergman" <no...@devtech.com>.
Gavin wrote:
> > Actually, I read Incubator e-mail pretty much every day.
> Then why do you store up all your replies until report time? It makes no
> sense.
I don't. I just haven't had much to say lately, although I did post earlier
about Zeta and NPanday. And, as you know, I was away last week.
> I can't help feeling irritated that you turn up once a month with your
> slew of emails and then think all is great again until the following
> months reporting period.
> Let's just only go as far back as January this year.
Er, I looked over your list. Did you miss e-mails on August 5? And
checking ALL of my general@ e-mails this year, the bulk of them have been
about the report, so naturally posted in that time frame.
> > The role of the PMC Chair is to make sure that the project
> > runs smoothly. I was very vocal during the formative days of the
> > Incubator, and speak up when I've something to say. Otherwise, I
> > am quite happy to see others stepping up and staking a role in the
> > Incubator.
> Ok, if you see all is well then fine, but can you not just at least look
> like you are a bit more interested other than just at reporting time?
You mean, like partcipating in this discussion, and the related one that
Greg just raised?
> you just posted a whole months worth at members requesting to join the
> Incubator PMC and Greg just acked the lot
The first was dated August 5th (the day before I left) to now. So, yes, I
got to all of them today after first doing the board report.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: an experiment
Posted by "Gav..." <ga...@16degrees.com.au>.
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: Tuesday, 17 August 2010 9:13 AM
> To: general@incubator.apache.org
> Subject: RE: an experiment
>
> Gavin McDonald wrote:
>
> > How about a PMC Chair that does more than turn up once a month at ,
> ooh,
> day
> > before board reports are due and then disappears for a whole month
> until ,
> > ooh, day before report time.
>
> Actually, I read Incubator e-mail pretty much every day.
Then why do you store up all your replies until report time? It makes no
sense.
>
> > And you still expect to run the whole show your way and jump in with
> 20+
> > messages in one day about subjects people have been discussing for
> days
> > if not weeks before.
>
> I'm voicing an opinion, backing it up, and taking the issue to the
> Board for
> their input. If I really expected to "run the whole show [my] way", I
> wouldn't make sure that as much as possible is delegated and
> distributed to
> the PMC, and I would be much more vocal. Personally, I believe that
> the
> Incubator runs smoothly precisely because of that delegation.
>
> In the specific case of Joe's experiment, I would have voice my opinion
> earlier, but was away. Please note that, as an Incubator PMC Member,
> you
> were notified of my schedule.
Yes, and if it were just this month then fine, but it's not. Why on earth
I notice these things I don't know, maybe it's not important in the grand
scheme of things, but I can't help feeling irritated that you turn up once
a month with your slew of emails and then think all is great again until
the following months reporting period.
Oh right, I need to back that up. Let's just only go as far back as January
this
year.
January board meeting was: 20th: you posted on 18th,19th.
February board meeting was: 17th: you posted on 15th,16th,24th.
March board meeting was: 17th: you posted on 16th.
April board meeting was: 21st: you posted on 20th,21st.
May board meeting was: 19th: you posted on 18th.
June board meeting was: 16th: you posted on 15th,18th.
July board meeting was: 21st: you posted on 19th,22nd.
Note that these dates are as I received them my TZ (GMT+9) but
you get the idea. I see a pattern.
>
> > And I can't wait for your excuse to be that the sole role of PMC
> chair is
> to
> > file reports.
>
> No, it isn't. The role of the PMC Chair is to make sure that the
> project
> runs smoothly. I was very vocal during the formative days of the
> Incubator,
> and speak up when I've something to say. Otherwise, I am quite happy
> to see
> others stepping up and staking a role in the Incubator.
Ok, if you see all is well then fine, but can you not just at least look
like you are a bit more interested other than just at reporting time?
another example, you just posted a whole months worth at members requesting
to join the Incubator PMC and Greg just acked the lot -- is this something
that only you as Incubator PMC chair can do or can any member send off this
ack request to the board? If it makes things easier I'd be glad to help.
Gav...
>
> --- Noel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Greg Stein <gs...@gmail.com>.
On Mon, Aug 16, 2010 at 19:12, Noel J. Bergman <no...@devtech.com> wrote:
> Gavin McDonald wrote:
>
>> How about a PMC Chair that does more than turn up once a month at , ooh,
> day
>> before board reports are due and then disappears for a whole month until ,
>> ooh, day before report time.
>
> Actually, I read Incubator e-mail pretty much every day.
How about showing your participation? You haven't committed to the
incubator svn in *years*.
>> And you still expect to run the whole show your way and jump in with 20+
>> messages in one day about subjects people have been discussing for days
>> if not weeks before.
>
> I'm voicing an opinion, backing it up, and taking the issue to the Board for
> their input. If I really expected to "run the whole show [my] way", I
> wouldn't make sure that as much as possible is delegated and distributed to
> the PMC, and I would be much more vocal. Personally, I believe that the
> Incubator runs smoothly precisely because of that delegation.
He has a fair point, so don't be too quick to the defense.
How long have you been the VP of Incubator? Would "new blood" be
something good or bad for the Incubator? Change things up, bring
different ideas and energy?
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Mon, Aug 16, 2010 at 2:32 PM, Gav... <ga...@16degrees.com.au> wrote:
> have something to say about it. I'm surprised no-one has mentioned about the
> Incubator PMC Chair
> up until now (actually I'm not, and I bet that no one steps up to agree with
> me here, I expect
> to be alone in my opinion.)
I agree with you.
I hate having to be cranky whenever I deal with the Incubator - it's
no fun. So, any experiments we can foster, yay, I want more - not
less. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: an experiment
Posted by "Noel J. Bergman" <no...@devtech.com>.
Gavin McDonald wrote:
> How about a PMC Chair that does more than turn up once a month at , ooh,
day
> before board reports are due and then disappears for a whole month until ,
> ooh, day before report time.
Actually, I read Incubator e-mail pretty much every day.
> And you still expect to run the whole show your way and jump in with 20+
> messages in one day about subjects people have been discussing for days
> if not weeks before.
I'm voicing an opinion, backing it up, and taking the issue to the Board for
their input. If I really expected to "run the whole show [my] way", I
wouldn't make sure that as much as possible is delegated and distributed to
the PMC, and I would be much more vocal. Personally, I believe that the
Incubator runs smoothly precisely because of that delegation.
In the specific case of Joe's experiment, I would have voice my opinion
earlier, but was away. Please note that, as an Incubator PMC Member, you
were notified of my schedule.
> And I can't wait for your excuse to be that the sole role of PMC chair is
to
> file reports.
No, it isn't. The role of the PMC Chair is to make sure that the project
runs smoothly. I was very vocal during the formative days of the Incubator,
and speak up when I've something to say. Otherwise, I am quite happy to see
others stepping up and staking a role in the Incubator.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: an experiment
Posted by "Gav..." <ga...@16degrees.com.au>.
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: Tuesday, 17 August 2010 4:07 AM
> To: general@incubator.apache.org
> Subject: RE: an experiment
>
> > Noel J. Bergman wrote:
> > > Your reading of the corporate structure of this org is needlessly
> formal.
> > And sometimes the job description of a PMC Chair is
>
> Sorry, got distracted by the phone, and didn't finish the thought.
>
> Part of the job description of a PMC Chair is to look after the
> Foundation's
> interests. I hope that no one would say that I take an obstructionist
> approach to our projects, but if the PMC Chair doesn't look at these
> issues,
> who will?
How about a PMC Chair that does more than turn up once a month at , ooh, day
before
board reports are due and then disappears for a whole month until , ooh, day
before
report time.
And you still expect to run the whole show your way and jump in with 20+
messages in one day
about subjects people have been discussing for days if not weeks before.
if (P)PMC chairs of other projects acted in this manner others including
yourself maybe, would
have something to say about it. I'm surprised no-one has mentioned about the
Incubator PMC Chair
up until now (actually I'm not, and I bet that no one steps up to agree with
me here, I expect
to be alone in my opinion.)
And I can't wait for your excuse to be that the sole role of PMC chair is to
file reports.
It's a shame because when you do turn up, you do a half decent job.
Now to catch up with the other 30+ messages that have steamed in these last
few hours.
Gav...
>
> --- Noel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: an experiment
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Noel J. Bergman wrote:
> > Your reading of the corporate structure of this org is needlessly
formal.
> And sometimes the job description of a PMC Chair is
Sorry, got distracted by the phone, and didn't finish the thought.
Part of the job description of a PMC Chair is to look after the Foundation's
interests. I hope that no one would say that I take an obstructionist
approach to our projects, but if the PMC Chair doesn't look at these issues,
who will?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: an experiment
Posted by "Noel J. Bergman" <no...@devtech.com>.
Joe Schaefer wrote:
> Are you trying to tell me that both jakarta and httpd have been in
violation
> of Apache bylaws all these years?
As as matter of fact, YES.
I can't speak for the HTTP Server situation, but in the case of Jakarta,
that was one of the reasons for breaking it up, along with pushing to make
every committer a PMC member. Before that, Jakarta had allowed projects to
vote their own releases outside of the PMC, and that finally raised some big
red flags. I remember that clearly, as I suspect would Serge and Danny.
> The fact that committers have no legal standing in this org means there is
> no reason a "decision" made about them needs formal approval by a PMC.
> Your reading of the corporate structure of this org is needlessly formal.
Giving them commit access has been deemed an action requiring a vote of the
PMC. And sometimes the job description of a PMC Chair is
> Amongst current board members are the ex-chair of Jakarta and an ex-chair
> of httpd. I would love to see you bring your concerns to the board about
> their past conduct regarding new committers.
No need. Sam was part of the process of fixing Jakarta, and Roy was one of
the one's posting about the problem in Jakarta.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Noel J. Bergman <no...@devtech.com>
> To: general@incubator.apache.org
> Sent: Mon, August 16, 2010 12:18:39 PM
> Subject: RE: an experiment
>
> > I'd like to start experimenting with different organizational
> > and procedural approaches to the projects I participate in
> > here. What I want to do is to see how far I can push
> > the envelope on the whole notion of empowerment and
> > self-governance in an incubating project, following the
> > lessons I've learned from httpd's treatment of the subprojects
> > it happens to be responsible for.
>
> The reason for the existence of the PPMC is to help foster that
> self-governance, but we must recognize two things. One, the projects are
> not yet entitled to full self-governance. That's why they are in the
> Incubator. Two, the ASF Bylaws name *the* governing body for each project
> as the PMC, which is required to provide oversight.
>
>
> > The first idea should be fairly straightforward: that for
> > the projects I participate in (so far thrift and sis), that
> > the IPMC delegates to the PPMC the decision-making process
> > for voting in new committers
>
> -1
>
> The PPMC has no legal or structural standing with the ASF. Decisions are
> made -- and required to be made -- by each project's PMC, as per the Bylaws.
Are you trying to tell me that both jakarta and httpd have been in violation
of Apache bylaws all these years?
> If the PPMC has 3 or more PMC members, it should be capable of mustering the
> necessary votes by virtue of those PMC members voting.
>
> Now, if the ASF Board would like to approve a different behavior, I'd accept
> that, but I don't believe that a PMC should take it on itself to skirt ASF
> Bylaws, and we've tried very hard to structure the Incubator within them.
Amongst current board members are the ex-chair of Jakarta and an ex-chair
of httpd. I would love to see you bring your concerns to the board about
their past conduct regarding new committers.
The fact that committers have no legal standing in this org means there is
no reason a "decision" made about them needs formal approval by a PMC.
Your reading of the corporate structure of this org is needlessly formal.
>
> > The second idea is more controversial: to hold IPMC votes to
> > admit all significant committers to those projects to the IPMC
> > itself. The purpose of this concept is to allow those who
> > best know the codebase to provide IPMC oversight over it,
> > especially as it pertains to releases.
>
> -1
>
> The Incubator PMC, unlike other PMCs, isn't preoccupied with the codebase;
> it is about community. And even with respect to code, we have far too much
> experience with projects attempt to put out improper releases to abandon our
> oversight obligations.
I'm actually sugggesting we *enhance* our oversight capabilities,
not abandon them.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Greg Stein <gs...@gmail.com>.
On Mon, Aug 16, 2010 at 22:29, Noel J. Bergman <no...@devtech.com> wrote:
> Greg Stein wrote:
>
>> > I read that thread, and as I commented on private@, I thought that it could
>> > have been handled better.
>
>> I certainly could have handled it better.
>
> I didn't mean by YOU. See my reply on private@ before jumping to that
> conclusion.
Well aware of that, but it doesn't make my statement any less true :-P
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Subversion full/partial committer (was: Re: an experiment)
Posted by Joe Schaefer <jo...@yahoo.com>.
FWIW Greg once complained about infra's use of machine names
in our board reports as being a bit too cloistered for the
board to follow coherently. To address this we added
parentheticals that associated more common service names
to the first usage of any hostname and so far the board has
found that to be a useful device.
Sounds like something similar will work for Subversion.
Kudos.
----- Original Message ----
> From: Daniel Shahaf <d....@daniel.shahaf.name>
> To: board@apache.org
> Cc: Incubator <ge...@incubator.apache.org>
> Sent: Tue, August 17, 2010 4:06:10 PM
> Subject: Re: Subversion full/partial committer (was: Re: an experiment)
>
> Greg Stein wrote on Tue, Aug 17, 2010 at 14:26:24 -0400:
> > On Tue, Aug 17, 2010 at 14:03, Craig L Russell <cr...@oracle.com>
>wrote:
> > > I don't care what you call them in the project. I'm asking that you use
> > > Apache terminology when discussing things among the wider Apache
>community.
>
> @Craig, thanks for clarifying your position/point.
>
> > The report is consumed by the svn community, too. They reviewed it and
> > provided feedback. It uses terms from the svn community.
> >
> > >...
> > >> In particular: lines 1710,1711,1717 of r24487 of the board agenda.
> > >
> > > Yes. I'd prefer to keep translations out of the discussion with the wider
> > > Apache community. If translation is needed (someone in the subversion
> > > community wants to understand the board report) then that's a matter for
>the
> > > subversion community not the wider Apache community.
> >
> > The svn-specific terms are basically parentheticals to the overall
> > report, so have no particular impact on its content.
>
> That's exactly what I was thinking: the report uses the ASF-wide terms
> ("committer" and "PMC Member") first, and only later adds the
> svn-specific bits (translations or concrete semantics) of those terms.
> This way seems to serve both those acquainted with the svn community
> structure and those unacquainted with it.
>
> > If any Directors
> > have an issue with those terms, then I would expect to see it in the
> > commentary section. Unless/until then, I'm going to avoid tweaking the
> > report since its current form has already been reviewed/accepted by
> > two Directors.
> >
> > Cheers,
> > -g
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Subversion full/partial committer (was: Re: an experiment)
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Greg Stein wrote on Tue, Aug 17, 2010 at 14:26:24 -0400:
> On Tue, Aug 17, 2010 at 14:03, Craig L Russell <cr...@oracle.com> wrote:
> > I don't care what you call them in the project. I'm asking that you use
> > Apache terminology when discussing things among the wider Apache community.
@Craig, thanks for clarifying your position/point.
> The report is consumed by the svn community, too. They reviewed it and
> provided feedback. It uses terms from the svn community.
>
> >...
> >> In particular: lines 1710,1711,1717 of r24487 of the board agenda.
> >
> > Yes. I'd prefer to keep translations out of the discussion with the wider
> > Apache community. If translation is needed (someone in the subversion
> > community wants to understand the board report) then that's a matter for the
> > subversion community not the wider Apache community.
>
> The svn-specific terms are basically parentheticals to the overall
> report, so have no particular impact on its content.
That's exactly what I was thinking: the report uses the ASF-wide terms
("committer" and "PMC Member") first, and only later adds the
svn-specific bits (translations or concrete semantics) of those terms.
This way seems to serve both those acquainted with the svn community
structure and those unacquainted with it.
> If any Directors
> have an issue with those terms, then I would expect to see it in the
> commentary section. Unless/until then, I'm going to avoid tweaking the
> report since its current form has already been reviewed/accepted by
> two Directors.
>
> Cheers,
> -g
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Subversion full/partial committer (was: Re: an experiment)
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Aug 19, 2010 at 16:20, Noel J. Bergman <no...@devtech.com> wrote:
>> > So it allows them to seamlessly earn wider karma via RTC?
>> Correct.
>
> So, it promotes CTR by the more experienced hands, and RTC by the less
> experienced hands. That does not seem like a bad thing.
Yup.
And to clarify: within their specified areas, the "partial committers"
have full CTR rights. It's only when they need/want to commit outside
of that scope that RTC kicks in. We further tweak this pattern to give
them CTR outside the scope for "obvious fixes", such as a typo in a
header file.
It is all explained at:
http://subversion.apache.org/docs/community-guide/roles.html#committers
Yes, it has worked out quite well as a way to groom committers into
larger responsibility. The bar is low to get partial commit access
(why not? anything can be reverted), but the move to full access (PMC
member now, too) takes a while to demonstrate capability, interest,
and whatnot. This is the same pattern as other ASF projects: continued
dedication gets an invitation to the PMC; although our initial commit
access bar is lower than most.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Subversion full/partial committer (was: Re: an experiment)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > So it allows them to seamlessly earn wider karma via RTC?
> Correct.
So, it promotes CTR by the more experienced hands, and RTC by the less
experienced hands. That does not seem like a bad thing.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Subversion full/partial committer (was: Re: an experiment)
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Aug 19, 2010 at 14:56, Noel J. Bergman <no...@devtech.com> wrote:
> Greg Stein wrote:
>
>> Actually, we don't use ACLs at all. We simply tell them "only commit
>> in your designated area". We haven't ever had a problem with that
>> approach.
>
> Even better. :-) Relies on human respect.
>
>> Even better: if the committer gets a +1 on a patch from somebody with
>> "full" access, then they can go ahead and commit outside their area.
>
> So it allows them to seamlessly earn wider karma via RTC? I believe that's
> what you said; just confirming.
Correct.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Subversion full/partial committer (was: Re: an experiment)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Greg Stein wrote:
> Actually, we don't use ACLs at all. We simply tell them "only commit
> in your designated area". We haven't ever had a problem with that
> approach.
Even better. :-) Relies on human respect.
> Even better: if the committer gets a +1 on a patch from somebody with
> "full" access, then they can go ahead and commit outside their area.
So it allows them to seamlessly earn wider karma via RTC? I believe that's
what you said; just confirming.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Subversion full/partial committer (was: Re: an experiment)
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Aug 19, 2010 at 13:29, Noel J. Bergman <no...@devtech.com> wrote:
>...
>> No way would the Board (nor you) allow arbitrary terminology across
>> projects even if it is "parentheticals" (whatever that means).
>
> As far as I'm concerned, the participants are Committers. There is no need
> to distinguish between them other than access rights in the SVN ACLs.
> Partitioning ACLs is really nothing more than infrastructure enforced
> behavior to make the PMC's required oversight task a bit safer (people who
> shouldn't be changing something can't). ACLs are controlled by each PMC,
> and represent infrastrucure enforcement of resource rights within the
> specific Community. As long as the Community is healthy and accepting of
> its own structure, I see no need to attack differences that aren't harmful.
Actually, we don't use ACLs at all. We simply tell them "only commit
in your designated area". We haven't ever had a problem with that
approach.
Even better: if the committer gets a +1 on a patch from somebody with
"full" access, then they can go ahead and commit outside their area.
It makes it very easy when the contributors can commit their own
patches :-)
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Subversion full/partial committer (was: Re: an experiment)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Joe Schaefer wrote:
> I'm perfectly comfortable letting the board provide feedback to Greg
> about its expectations for future Subversion reports, and see no need
> for anyone else to insert their opinions on the subject in any more
> than a limited and advisory basis.
I'm still trying to figure out (metaphorically speaking) how this discussion
ended up HERE. :-)
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Subversion full/partial committer (was: Re: an experiment)
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Craig L Russell wrote on Thu, Aug 19, 2010 at 15:45:54 -0700:
> I wish we had completed this discussion while subversion was still in
> incubation, while the subversion community could learn the common Apache
> terminology and have no need for translation of the terms.
>
> Instead, a suggestion to that effect was brutally shot down.
>
> And since it's apparently not clear what my point is, I'll repeat it:
>
> Apache has a common set of terms that everyone who participates is
> expected to understand. They are documented in the foundation "How we
> work" pages.
>
> Projects are free to have their own set of rules and terminology. If
> they differ much from standard Apache governance, there's an opportunity
> for them to have their own bylaws.
>
> When communicating with the wider Apache community, the standard terms
> are all that are needed. Parentheticals in such things as board reports,
> which are widely disseminated, might seem useful early in the project but
> are unnecessary very quickly. If they serve to clarify for the wider
> community, ok. But if parentheticals' only purpose is project
> communication, I believe that they are best avoided, as project members
> should know the Apache terminology (before exiting incubation).
>
I think the parentheticals are useful for Subversion community members
(who aren't PMC members) who read our board report, and for people who
read the board report and then want to better acquaint themselves with
our community.
Anyway, these terms exist in the community, as much as "RA layer" is a
term in our community. Let's not pretend they don't exist.
> Craig
>
> On Aug 19, 2010, at 2:17 PM, Joe Schaefer wrote:
>
>> Didn't you just suggest that Greg summarily drop
>> his use of local terminology from his reports, and
>> don't you consider the Subversion report a community
>> document, and therefore of educational value for the
>> wider community, not just the pmc, in some sense?
>>
>>
>> ----- Original Message ----
>>> From: Craig L Russell <cr...@oracle.com>
>>> To: general@incubator.apache.org
>>> Sent: Thu, August 19, 2010 4:09:19 PM
>>> Subject: Re: Subversion full/partial committer (was: Re: an
>>> experiment)
>>>
>>> Hi Joe,
>>>
>>> Please read my messages again. I'm not suggesting anything of the
>>> sort.
>>>
>>> Craig
>>>
>>> On Aug 19, 2010, at 11:45 AM, Joe Schaefer wrote:
>>>
>>>> Cmon Craig. Subversion is a 10-year old community. Making major
>>>> changes
>>>> in basic terminology isn't something that happens in a day.
>>>>
>>>
>>> Craig L Russell
>>> Architect, Oracle
>>> http://db.apache.org/jdo
>>> 408 276-5638 mailto:Craig.Russell@oracle.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
> Craig L Russell
> Architect, Oracle
> http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@oracle.com
> P.S. A good JDO? O, Gasp!
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Subversion full/partial committer (was: Re: an experiment)
Posted by Greg Stein <gs...@gmail.com>.
Oh, I totally understand what you're saying.
And I respectfully and totally disagree with it on several levels.
We can leave it at that, or you can propose a Resolution to the Board
to enforce terminology whenever different communities want to
communicate here at Apache. Should the Board pass such a resolution,
then the svn community will conform. We are not special; we just use
different terms. All projects are given broad leeway in how they run
their project. That *is* part of the Apache Way. We are very slightly
"non-standard" in one way, and other projects differ in other ways. If
you want to iron out those disparities, then get a Board Resolution to
do it.
Cheers,
-g
On Thu, Aug 19, 2010 at 18:45, Craig L Russell <cr...@oracle.com> wrote:
> I wish we had completed this discussion while subversion was still in
> incubation, while the subversion community could learn the common Apache
> terminology and have no need for translation of the terms.
>
> Instead, a suggestion to that effect was brutally shot down.
>
> And since it's apparently not clear what my point is, I'll repeat it:
>
> Apache has a common set of terms that everyone who participates is expected
> to understand. They are documented in the foundation "How we work" pages.
>
> Projects are free to have their own set of rules and terminology. If they
> differ much from standard Apache governance, there's an opportunity for them
> to have their own bylaws.
>
> When communicating with the wider Apache community, the standard terms are
> all that are needed. Parentheticals in such things as board reports, which
> are widely disseminated, might seem useful early in the project but are
> unnecessary very quickly. If they serve to clarify for the wider community,
> ok. But if parentheticals' only purpose is project communication, I believe
> that they are best avoided, as project members should know the Apache
> terminology (before exiting incubation).
>
> Craig
>
> On Aug 19, 2010, at 2:17 PM, Joe Schaefer wrote:
>
>> Didn't you just suggest that Greg summarily drop
>> his use of local terminology from his reports, and
>> don't you consider the Subversion report a community
>> document, and therefore of educational value for the
>> wider community, not just the pmc, in some sense?
>>
>>
>> ----- Original Message ----
>>>
>>> From: Craig L Russell <cr...@oracle.com>
>>> To: general@incubator.apache.org
>>> Sent: Thu, August 19, 2010 4:09:19 PM
>>> Subject: Re: Subversion full/partial committer (was: Re: an experiment)
>>>
>>> Hi Joe,
>>>
>>> Please read my messages again. I'm not suggesting anything of the sort.
>>>
>>> Craig
>>>
>>> On Aug 19, 2010, at 11:45 AM, Joe Schaefer wrote:
>>>
>>>> Cmon Craig. Subversion is a 10-year old community. Making major
>>>> changes
>>>> in basic terminology isn't something that happens in a day.
>>>>
>>>
>>> Craig L Russell
>>> Architect, Oracle
>>> http://db.apache.org/jdo
>>> 408 276-5638 mailto:Craig.Russell@oracle.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
> Craig L Russell
> Architect, Oracle
> http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@oracle.com
> P.S. A good JDO? O, Gasp!
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Subversion full/partial committer (was: Re: an experiment)
Posted by Tim Williams <wi...@gmail.com>.
On Thu, Aug 19, 2010 at 6:45 PM, Craig L Russell
<cr...@oracle.com> wrote:
> I wish we had completed this discussion while subversion was still in
> incubation, while the subversion community could learn the common Apache
> terminology and have no need for translation of the terms.
>
> Instead, a suggestion to that effect was brutally shot down.
>
> And since it's apparently not clear what my point is, I'll repeat it:
>
> Apache has a common set of terms that everyone who participates is expected
> to understand. They are documented in the foundation "How we work" pages.
>
> Projects are free to have their own set of rules and terminology. If they
> differ much from standard Apache governance, there's an opportunity for them
> to have their own bylaws.
>
> When communicating with the wider Apache community, the standard terms are
> all that are needed. Parentheticals in such things as board reports, which
> are widely disseminated, might seem useful early in the project but are
> unnecessary very quickly. If they serve to clarify for the wider community,
> ok. But if parentheticals' only purpose is project communication, I believe
> that they are best avoided, as project members should know the Apache
> terminology (before exiting incubation).
Who cares? This reeks to me of bureaucracy one might find at a
$dayjob. I mean, the "apache" terms were used in the report, the
parentheticals were project-specific. Eventually, they might simply
realize that the apache terminology is cool enough to use directly.
All board members are apparently competent enough to ignore the
parentheticals in their mind's eye - if they had a problem, they would
have mentioned it. All will be ok, really. This thread, like Joe's
thread, makes me wonder how such a pioneering group got such an
obeying/mother-may-i culture - it's nearly embarrassing.
--tim
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Subversion full/partial committer (was: Re: an experiment)
Posted by Craig L Russell <cr...@oracle.com>.
On Aug 19, 2010, at 6:32 PM, Joe Schaefer wrote:
> Hm, sounds like sour grapes reappearing. Having the subversion
> community
> drop 10 years of common terminology and quickly adopt ours isn't
> what I
> consider part and parcel of incubation.
I guess I have to say it again. I'm not suggesting that the subversion
community drop their terminology.
Craig
Craig L Russell
Architect, Oracle
http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@oracle.com
P.S. A good JDO? O, Gasp!
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Subversion full/partial committer (was: Re: an experiment)
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Craig L Russell <cr...@oracle.com>
> To: general@incubator.apache.org
> Sent: Thu, August 19, 2010 6:45:54 PM
> Subject: Re: Subversion full/partial committer (was: Re: an experiment)
>
> I wish we had completed this discussion while subversion was still in
>incubation, while the subversion community could learn the common Apache
>terminology and have no need for translation of the terms.
>
> Instead, a suggestion to that effect was brutally shot down.
Hm, sounds like sour grapes reappearing. Having the subversion community
drop 10 years of common terminology and quickly adopt ours isn't what I
consider part and parcel of incubation. As that community continues to proceed
through the hallways and corridors of Apache, they will find less friction
when they talk about their project to other Apache people using terms that
Apache people can readily relate to. They can do that while at the same
time supporting local terminology specific to subversion, for as long as
they can maintain the two modes of speaking.
IOW, this does not require a top-down approach with a strict time-limit.
Subversion will pick up our terms naturally and probably phase out their
own just for the sake of having simplified their discussions with various
folks. We do not need to prod them; they will either see it as being in
their own best interests or will deal with the duality.
>
> And since it's apparently not clear what my point is, I'll repeat it:
>
> Apache has a common set of terms that everyone who participates is expected to
>understand. They are documented in the foundation "How we work" pages.
>
> Projects are free to have their own set of rules and terminology. If they
>differ much from standard Apache governance, there's an opportunity for them to
>have their own bylaws.
>
> When communicating with the wider Apache community, the standard terms are all
>that are needed. Parentheticals in such things as board reports, which are
>widely disseminated, might seem useful early in the project but are unnecessary
>very quickly. If they serve to clarify for the wider community, ok. But if
>parentheticals' only purpose is project communication, I believe that they are
>best avoided, as project members should know the Apache terminology (before
>exiting incubation).
Fair enough.
>
> Craig
>
> On Aug 19, 2010, at 2:17 PM, Joe Schaefer wrote:
>
> > Didn't you just suggest that Greg summarily drop
> > his use of local terminology from his reports, and
> > don't you consider the Subversion report a community
> > document, and therefore of educational value for the
> > wider community, not just the pmc, in some sense?
> >
> >
> > ----- Original Message ----
> >> From: Craig L Russell <cr...@oracle.com>
> >> To: general@incubator.apache.org
> >> Sent: Thu, August 19, 2010 4:09:19 PM
> >> Subject: Re: Subversion full/partial committer (was: Re: an experiment)
> >>
> >> Hi Joe,
> >>
> >> Please read my messages again. I'm not suggesting anything of the sort.
> >>
> >> Craig
> >>
> >> On Aug 19, 2010, at 11:45 AM, Joe Schaefer wrote:
> >>
> >>> Cmon Craig. Subversion is a 10-year old community. Making major
changes
> >>> in basic terminology isn't something that happens in a day.
> >>>
> >>
> >> Craig L Russell
> >> Architect, Oracle
> >> http://db.apache.org/jdo
> >> 408 276-5638 mailto:Craig.Russell@oracle.com
> >> P.S. A good JDO? O, Gasp!
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >>
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
>
> Craig L Russell
> Architect, Oracle
> http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@oracle.com
> P.S. A good JDO? O, Gasp!
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Subversion full/partial committer (was: Re: an experiment)
Posted by Craig L Russell <cr...@oracle.com>.
I wish we had completed this discussion while subversion was still in
incubation, while the subversion community could learn the common
Apache terminology and have no need for translation of the terms.
Instead, a suggestion to that effect was brutally shot down.
And since it's apparently not clear what my point is, I'll repeat it:
Apache has a common set of terms that everyone who participates is
expected to understand. They are documented in the foundation "How we
work" pages.
Projects are free to have their own set of rules and terminology. If
they differ much from standard Apache governance, there's an
opportunity for them to have their own bylaws.
When communicating with the wider Apache community, the standard terms
are all that are needed. Parentheticals in such things as board
reports, which are widely disseminated, might seem useful early in the
project but are unnecessary very quickly. If they serve to clarify for
the wider community, ok. But if parentheticals' only purpose is
project communication, I believe that they are best avoided, as
project members should know the Apache terminology (before exiting
incubation).
Craig
On Aug 19, 2010, at 2:17 PM, Joe Schaefer wrote:
> Didn't you just suggest that Greg summarily drop
> his use of local terminology from his reports, and
> don't you consider the Subversion report a community
> document, and therefore of educational value for the
> wider community, not just the pmc, in some sense?
>
>
> ----- Original Message ----
>> From: Craig L Russell <cr...@oracle.com>
>> To: general@incubator.apache.org
>> Sent: Thu, August 19, 2010 4:09:19 PM
>> Subject: Re: Subversion full/partial committer (was: Re: an
>> experiment)
>>
>> Hi Joe,
>>
>> Please read my messages again. I'm not suggesting anything of the
>> sort.
>>
>> Craig
>>
>> On Aug 19, 2010, at 11:45 AM, Joe Schaefer wrote:
>>
>>> Cmon Craig. Subversion is a 10-year old community. Making major
>>> changes
>>> in basic terminology isn't something that happens in a day.
>>>
>>
>> Craig L Russell
>> Architect, Oracle
>> http://db.apache.org/jdo
>> 408 276-5638 mailto:Craig.Russell@oracle.com
>> P.S. A good JDO? O, Gasp!
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Craig L Russell
Architect, Oracle
http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@oracle.com
P.S. A good JDO? O, Gasp!
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Subversion full/partial committer (was: Re: an experiment)
Posted by Joe Schaefer <jo...@yahoo.com>.
Didn't you just suggest that Greg summarily drop
his use of local terminology from his reports, and
don't you consider the Subversion report a community
document, and therefore of educational value for the
wider community, not just the pmc, in some sense?
----- Original Message ----
> From: Craig L Russell <cr...@oracle.com>
> To: general@incubator.apache.org
> Sent: Thu, August 19, 2010 4:09:19 PM
> Subject: Re: Subversion full/partial committer (was: Re: an experiment)
>
> Hi Joe,
>
> Please read my messages again. I'm not suggesting anything of the sort.
>
> Craig
>
> On Aug 19, 2010, at 11:45 AM, Joe Schaefer wrote:
>
> > Cmon Craig. Subversion is a 10-year old community. Making major changes
> > in basic terminology isn't something that happens in a day.
> >
>
> Craig L Russell
> Architect, Oracle
> http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@oracle.com
> P.S. A good JDO? O, Gasp!
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Subversion full/partial committer (was: Re: an experiment)
Posted by Craig L Russell <cr...@oracle.com>.
Hi Joe,
Please read my messages again. I'm not suggesting anything of the sort.
Craig
On Aug 19, 2010, at 11:45 AM, Joe Schaefer wrote:
> Cmon Craig. Subversion is a 10-year old community. Making major
> changes
> in basic terminology isn't something that happens in a day.
>
Craig L Russell
Architect, Oracle
http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@oracle.com
P.S. A good JDO? O, Gasp!
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Subversion full/partial committer (was: Re: an experiment)
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Craig L Russell <cr...@oracle.com>
> To: general@incubator.apache.org
> Sent: Thu, August 19, 2010 2:38:48 PM
> Subject: Re: Subversion full/partial committer (was: Re: an experiment)
>
>
> On Aug 19, 2010, at 11:30 AM, Greg Stein wrote:
>
> > As I said in my other post, by using *both* sets of terms in the
> > report, the svn community also learns what the "formal" names are here
> > at the ASF. They can see the translation.
> >
> > So yeah. I'm doing exactly what you're asking: educating the community
> > on what a report looks like and what the proper terms should be.
> >
> >> ...
> >
> > Cheers,
> > -g
>
> I'll be happy if the education of the subversion pmc reviewers has now
> happened and you can simply use the accepted Apache terms henceforth.
Cmon Craig. Subversion is a 10-year old community. Making major changes
in basic terminology isn't something that happens in a day.
I'm perfectly comfortable letting the board provide feedback to Greg
about its expectations for future Subversion reports, and see no need
for anyone else to insert their opinions on the subject in any more
than a limited and advisory basis.
Peace.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Subversion full/partial committer (was: Re: an experiment)
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Craig L Russell wrote on Thu, Aug 19, 2010 at 11:38:48 -0700:
>
> On Aug 19, 2010, at 11:30 AM, Greg Stein wrote:
>
>> As I said in my other post, by using *both* sets of terms in the
>> report, the svn community also learns what the "formal" names are here
>> at the ASF. They can see the translation.
>>
>> So yeah. I'm doing exactly what you're asking: educating the community
>> on what a report looks like and what the proper terms should be.
>>
>>> ...
>>
>> Cheers,
>> -g
>
> I'll be happy if the education of the subversion pmc reviewers has now
> happened and you can simply use the accepted Apache terms henceforth.
The board report does use the ASF-wide terms. Are you suggesting it
should not use the common Subversion-community terms?
I can't see what the benefit of that would be?
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Subversion full/partial committer (was: Re: an experiment)
Posted by Craig L Russell <cr...@oracle.com>.
On Aug 19, 2010, at 11:30 AM, Greg Stein wrote:
> As I said in my other post, by using *both* sets of terms in the
> report, the svn community also learns what the "formal" names are here
> at the ASF. They can see the translation.
>
> So yeah. I'm doing exactly what you're asking: educating the community
> on what a report looks like and what the proper terms should be.
>
>> ...
>
> Cheers,
> -g
I'll be happy if the education of the subversion pmc reviewers has now
happened and you can simply use the accepted Apache terms henceforth.
Craig
Craig L Russell
Architect, Oracle
http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@oracle.com
P.S. A good JDO? O, Gasp!
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Subversion full/partial committer (was: Re: an experiment)
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Aug 19, 2010 at 10:06, Niclas Hedhman <ni...@hedhman.org> wrote:
> On Wed, Aug 18, 2010 at 2:26 AM, Greg Stein <gs...@gmail.com> wrote:
>...
>> The report is consumed by the svn community, too. They reviewed it and
>> provided feedback. It uses terms from the svn community.
>...
> No way would the Board (nor you) allow arbitrary terminology across
> projects even if it is "parentheticals" (whatever that means). You
Here is a definition I found, and it matches my intent:
parenthetical: Set off within or as if within parentheses; qualifying
or explanatory
> would shoot such project down faster than they could type it out in
> the report.
Euh. Go read the reports some time. There are lots of PMC-specific
terms in those reports. We understand them from experience, context,
or putting a query back to the PMC. I doubt the Board really cares
about the terms, as long as they can understand the report.
>...
> judgment when you are holding fast to this view that projects (at
> least Subversion!) can change the terminology in board reports because
> they are too lazy to change.
The Board report uses normal terminology, and supplements that with
svn terminology. Go read it; I posted it else-thread.
>...
> why
> not spend a little effort on educating the Subversion community to go
> with the flow. How fking hard can that be??
As I said in my other post, by using *both* sets of terms in the
report, the svn community also learns what the "formal" names are here
at the ASF. They can see the translation.
So yeah. I'm doing exactly what you're asking: educating the community
on what a report looks like and what the proper terms should be.
>...
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Subversion full/partial committer (was: Re: an experiment)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Niclas Hedhman wrote:
> Greg Stein wrote:
>> Craig L Russell wrote:
>>> I don't care what you call them in the project. I'm asking that you use
>>> Apache terminology when discussing things among the wider Apache
community.
>> The report is consumed by the svn community, too. They reviewed it and
>> provided feedback. It uses terms from the svn community.
> Greg, your position is just a pile of BS. You should know it.
Niclas, I request that you refrain from that kind of statement, and
apologize to Greg (off-list is fine). We can agree to disagree in a more
civil manner.
Moving on ...
> No way would the Board (nor you) allow arbitrary terminology across
> projects even if it is "parentheticals" (whatever that means).
As far as I'm concerned, the participants are Committers. There is no need
to distinguish between them other than access rights in the SVN ACLs.
Partitioning ACLs is really nothing more than infrastructure enforced
behavior to make the PMC's required oversight task a bit safer (people who
shouldn't be changing something can't). ACLs are controlled by each PMC,
and represent infrastrucure enforcement of resource rights within the
specific Community. As long as the Community is healthy and accepting of
its own structure, I see no need to attack differences that aren't harmful.
The tone of the rest of your message was, at least in my opinion, overly
aggressive and harsh, and therefore not well designed to be convincing. And
certainly didn't need airing in that manner on a public mailing list.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Subversion full/partial committer (was: Re: an experiment)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wed, Aug 18, 2010 at 2:26 AM, Greg Stein <gs...@gmail.com> wrote:
> On Tue, Aug 17, 2010 at 14:03, Craig L Russell <cr...@oracle.com> wrote:
>> I don't care what you call them in the project. I'm asking that you use
>> Apache terminology when discussing things among the wider Apache community.
>
> The report is consumed by the svn community, too. They reviewed it and
> provided feedback. It uses terms from the svn community.
Greg,
your position is just a pile of BS. You should know it.
No way would the Board (nor you) allow arbitrary terminology across
projects even if it is "parentheticals" (whatever that means). You
would shoot such project down faster than they could type it out in
the report. Now, you are so darn protective of this project, for all
good reasons, but I think your emotional attachment is clouding your
judgment when you are holding fast to this view that projects (at
least Subversion!) can change the terminology in board reports because
they are too lazy to change.
So, instead of bullying the ASF into accepting Subversion as it is,
without any need to conform any more than it does by 'default', why
not spend a little effort on educating the Subversion community to go
with the flow. How fking hard can that be??
Subversion already got more preferential treatment than it should, all
because of your bullying tactics.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Subversion full/partial committer (was: Re: an experiment)
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Aug 17, 2010 at 14:03, Craig L Russell <cr...@oracle.com> wrote:
>...
>> Craig L Russell wrote on Tue, Aug 17, 2010 at 09:42:18 -0700:
>...
> I don't care what you call them in the project. I'm asking that you use
> Apache terminology when discussing things among the wider Apache community.
The report is consumed by the svn community, too. They reviewed it and
provided feedback. It uses terms from the svn community.
>...
>> In particular: lines 1710,1711,1717 of r24487 of the board agenda.
>
> Yes. I'd prefer to keep translations out of the discussion with the wider
> Apache community. If translation is needed (someone in the subversion
> community wants to understand the board report) then that's a matter for the
> subversion community not the wider Apache community.
The svn-specific terms are basically parentheticals to the overall
report, so have no particular impact on its content. If any Directors
have an issue with those terms, then I would expect to see it in the
commentary section. Unless/until then, I'm going to avoid tweaking the
report since its current form has already been reviewed/accepted by
two Directors.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Subversion full/partial committer (was: Re: an experiment)
Posted by Craig L Russell <cr...@oracle.com>.
Hi Daniel,
On Aug 17, 2010, at 10:43 AM, Daniel Shahaf wrote:
> Craig L Russell wrote on Tue, Aug 17, 2010 at 09:42:18 -0700:
>> One of the first things you learn in Apache is that there are (at
>> least)
>> three levels of involvement that community members can take:
>> contributor, committer, PMC member. See "how it works, roles, etc.
>> etc."
>> on the Apache site.
>>
>> Now the subversion project comes in where these are not the commonly
>> used terms. Instead, the terms for committer and PMC member are
>> partial
>> committer and full committer. That's fine for the established
>> community,
>> but the translation from committer -> partial committer and PMC
>> member ->
>> full committer needs to be done within the project, not within
>> Apache.
>>
>
> Subversion doesn't have a concept of "has CTR commit access to the
> entire tree, but is not a PMC member". (That would be something
> between
> partial committer and full committer.) So, IIUC, it's more than
> terminology difference; it's a semantic difference.
>
> (In Subversion, adding to the PMC and granting tree-wide CTR commit
> access have always been done simultaneously.)
And I don't want to get involved in understanding the CRT, RTC, full,
partial, and other semantic differences in your project. Many projects
use various terms and practices to describe how they govern their
projects. Other projects have sandboxes, site committers, wiki
"committers", etc. and the subtleties are not really important to
raise to the board. I think that if you report to the board that
you've granted commit access to someone, that's a fact and additional
color is not necessary.
>
>> When I saw this month's board report for Subversion, I was taken
>> aback
>> that the board is expected to follow the terminology used by only one
>> project. Really? The board, which has used the same terms for 10++
>> years, is now going to hear reports of full committers and partial
>> committers? What do we do when another project comes in and uses yet
>> different terms for the same concept? Do we now make a translation
>> manual for everyone in Apache to use?
>>
>
> Subversion *has* used these terms for a few years too. Should we just
> stop using the terms we've used for N years?
I don't care what you call them in the project. I'm asking that you
use Apache terminology when discussing things among the wider Apache
community.
>
> <if 0>pun about svn folks being unable to forget their history</if>
>
>> My $.02: if you want to talk about full and partial committers in the
>> Apache community, there's more work to do so everyone gets on board
>> with
>> your terminology. Otherwise, communications will be enhanced if you
>> keep
>> full and partial committers to yourselves and translate to the
>> commonly
>> used Apache terms when dealing with the Apache community.
>>
>> And yes, I'd like to see the Subversion board report amended to
>> remove
>> references to full and partial.
>>
>
> Did you read the report?
Why, yes, I did read the report. I figured I would before commenting
on the report.
>
> In particular: lines 1710,1711,1717 of r24487 of the board agenda.
Yes. I'd prefer to keep translations out of the discussion with the
wider Apache community. If translation is needed (someone in the
subversion community wants to understand the board report) then that's
a matter for the subversion community not the wider Apache community.
Craig
>
>> Craig
>>
>> Craig L Russell
>> Architect, Oracle
>> http://db.apache.org/jdo
>> 408 276-5638 mailto:Craig.Russell@oracle.com
>> P.S. A good JDO? O, Gasp!
>>
Craig L Russell
Architect, Oracle
http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@oracle.com
P.S. A good JDO? O, Gasp!
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Subversion full/partial committer (was: Re: an experiment)
Posted by Ralph Goers <ra...@dslextreme.com>.
On Aug 19, 2010, at 11:25 AM, Greg Stein wrote:
>
> ----
> ** Community
>
> Since our last report, in May, we have added two more committers.
> These are "partial" committers, meaning they are restricted to certain
> portions of the tree. The first, artagnon, is a GSoC student for
> Git(!) and is adding a new "svnrdump" client-side tool to produce or
> load Subversion dump files remotely (eg. for fast-loading into Git).
> The second, stefan2, is working on a branch with a broad set of
> performance improvements across the system.
>
> No new PMC Members ("full committers") have been added.
> ----
>
> As you can see, we aren't trying to foist new terminology on anybody.
>
> I continue to believe that the terminology used in our report is fine.
> The Board showed no concern during the meeting. This ruckus seems
> quite overblown.
>
> Cheers,
> -g
>
This seems fair enough. In practice what you are doing is not much different than commons restricting committers to the sandbox, or when I got access to logging I was restricted to Log4j 2.0, not the current trunk. so I have no problem with the practice of granting restricted or partial access. I've just never seen the term "partial" committer before and certainly never used "full committer" to be analogous to a PMC member. Cocoon follows the same practice of making someone a PMC member when they are offered commit access, but we have still always announced them as a new committer and then invited them to also be on the PMC. We've also run into a couple of cases where we invited someone to be on the PMC due to their contribution to the community but they didn't really need commit access.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Subversion full/partial committer (was: Re: an experiment)
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Aug 19, 2010 at 10:03, Ralph Goers <ra...@dslextreme.com> wrote:
>...
> This seems really simple to me. If I move from Korea to the United States I'd better start learning to speak English if I want to interact with the population at large. If I just want to stay within my little Korean community then I can continue to speak my native language all that I want. Even an American living in the south needs to learn "proper" English if they want to run for a national office and be effective.
Oh, I totally understand.
> That said, American English is constantly evolving. If the ASF as a whole wants to adopt terms like "Full Committer" and "Partial Committer" than I'd expect to see a definition somewhere. As it stands, I must have missed the email where they were defined. Without that context I'm left to assume a "Partial Committer" is somehow handicapped or missing a few body parts, or a "Full Committer" is someone like me with a little too much weight on their torso.
http://subversion.apache.org/docs/community-guide/roles.html#committers
> The "cost" here is that a decently large project integrated with a larger organization and in doing so simply needs to be able to communicate effectively. That means a) getting the organization to recognize and accept the different terminology being used or b) stop using that terminology when speaking to the larger audience. Option a isn't accomplished by simply using the terminology and expecting everyone else to conform.
The Board report uses the term "committer" and "PMC member". It also
uses "partial" and "full", but those simply augment the report and are
present because the svn community is a consumer/producer of this
report. It makes it easier for that community, *and* it also helps to
teach the community what our "ASF names" are for the svn concepts. The
svn community *is* still learning about the ASF, after all.
Here is the section in question:
----
** Community
Since our last report, in May, we have added two more committers.
These are "partial" committers, meaning they are restricted to certain
portions of the tree. The first, artagnon, is a GSoC student for
Git(!) and is adding a new "svnrdump" client-side tool to produce or
load Subversion dump files remotely (eg. for fast-loading into Git).
The second, stefan2, is working on a branch with a broad set of
performance improvements across the system.
No new PMC Members ("full committers") have been added.
----
As you can see, we aren't trying to foist new terminology on anybody.
I continue to believe that the terminology used in our report is fine.
The Board showed no concern during the meeting. This ruckus seems
quite overblown.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Subversion full/partial committer (was: Re: an experiment)
Posted by Ralph Goers <ra...@dslextreme.com>.
On Aug 18, 2010, at 5:19 PM, Greg Stein wrote:
>
>
>> identifying the project with the ASF. Similarly on many occasions we have
>> asked projects to pick a new name as part of the incubation process. We have
>> made exceptions for well established brands (ServiceMix & ActiveMQ were the
>> first I remember but there probably were others) and so we do have precedent
>> for that (and I *totally* agree changing the name would accomplish nothing
>> here). IIRC even ServiceMix and ActiveMQ changed their package names to
>> org.apache.*.
>
> It seems somewhere that we disconnected from some conceptual
> terminology into an area of product/package naming.
>
This seems really simple to me. If I move from Korea to the United States I'd better start learning to speak English if I want to interact with the population at large. If I just want to stay within my little Korean community then I can continue to speak my native language all that I want. Even an American living in the south needs to learn "proper" English if they want to run for a national office and be effective.
That said, American English is constantly evolving. If the ASF as a whole wants to adopt terms like "Full Committer" and "Partial Committer" than I'd expect to see a definition somewhere. As it stands, I must have missed the email where they were defined. Without that context I'm left to assume a "Partial Committer" is somehow handicapped or missing a few body parts, or a "Full Committer" is someone like me with a little too much weight on their torso.
The "cost" here is that a decently large project integrated with a larger organization and in doing so simply needs to be able to communicate effectively. That means a) getting the organization to recognize and accept the different terminology being used or b) stop using that terminology when speaking to the larger audience. Option a isn't accomplished by simply using the terminology and expecting everyone else to conform.
Ralph
Re: Subversion full/partial committer (was: Re: an experiment)
Posted by Greg Stein <gs...@gmail.com>.
On Wed, Aug 18, 2010 at 20:06, Sanjiva Weerawarana
<sa...@opensource.lk> wrote:
> On Thu, Aug 19, 2010 at 3:41 AM, Greg Stein <gs...@gmail.com> wrote:
>> How does naming accomplish the goal of collaborative, consensus-based
>> development? I thought that was why we were here. I hadn't heard that
>
> We force Java code to be package changed to be org.apache.*. Why do we do
> that? That's a SERIOUS pain to all users but we do it - that's part of
You cannot possibly try to compare terminology to a *release artifact*.
We impose rules on our releases. The majority our rules apply to those
artifacts or their production.
> identifying the project with the ASF. Similarly on many occasions we have
> asked projects to pick a new name as part of the incubation process. We have
> made exceptions for well established brands (ServiceMix & ActiveMQ were the
> first I remember but there probably were others) and so we do have precedent
> for that (and I *totally* agree changing the name would accomplish nothing
> here). IIRC even ServiceMix and ActiveMQ changed their package names to
> org.apache.*.
It seems somewhere that we disconnected from some conceptual
terminology into an area of product/package naming.
>> people and projects had to pay a "price" to be part of the Foundation.
>
> There is of course a price- you can't have a BDFL (which many FOSS projects
> do), you have to report to the board every month first and then every 3
> months, you have to follow a certain decision making process we call the
> Apache Way etc. etc..
>
> For an established project which has its own structure those are all part of
> the "price" of being in the ASF. Nothin' wrong with it at all IMO: All good
> things come at a price.
Ah. Heh. I don't see those as a price/cost, so I still don't see what
you mean. ;-)
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Subversion full/partial committer (was: Re: an experiment)
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Thu, Aug 19, 2010 at 3:41 AM, Greg Stein <gs...@gmail.com> wrote:
>
> How does naming accomplish the goal of collaborative, consensus-based
> development? I thought that was why we were here. I hadn't heard that
>
We force Java code to be package changed to be org.apache.*. Why do we do
that? That's a SERIOUS pain to all users but we do it - that's part of
identifying the project with the ASF. Similarly on many occasions we have
asked projects to pick a new name as part of the incubation process. We have
made exceptions for well established brands (ServiceMix & ActiveMQ were the
first I remember but there probably were others) and so we do have precedent
for that (and I *totally* agree changing the name would accomplish nothing
here). IIRC even ServiceMix and ActiveMQ changed their package names to
org.apache.*.
> people and projects had to pay a "price" to be part of the Foundation.
>
There is of course a price- you can't have a BDFL (which many FOSS projects
do), you have to report to the board every month first and then every 3
months, you have to follow a certain decision making process we call the
Apache Way etc. etc..
For an established project which has its own structure those are all part of
the "price" of being in the ASF. Nothin' wrong with it at all IMO: All good
things come at a price.
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder, Director & Chief Scientist; Lanka Software Foundation;
http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Director; Sahana Software Foundation; http://www.sahanafoundation.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Blog: http://sanjiva.weerawarana.org/
Re: Subversion full/partial committer (was: Re: an experiment)
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Thu, Aug 19, 2010 at 12:11 AM, Greg Stein <gs...@gmail.com> wrote:
> On Wed, Aug 18, 2010 at 18:02, Sanjiva Weerawarana
> <sa...@opensource.lk> wrote:
>> On Tue, Aug 17, 2010 at 11:13 PM, Daniel Shahaf <d....@daniel.shahaf.name>wrote:
>>> > When I saw this month's board report for Subversion, I was taken aback
>>> > that the board is expected to follow the terminology used by only one
>>> > project. Really? The board, which has used the same terms for 10++
>>> > years, is now going to hear reports of full committers and partial
>>> > committers? What do we do when another project comes in and uses yet
>>> > different terms for the same concept? Do we now make a translation
>>> > manual for everyone in Apache to use?
>>> >
>>>
>>> Subversion *has* used these terms for a few years too. Should we just
>>> stop using the terms we've used for N years?
>>
>> Yes .. that's part of the price of being in the ASF! We have forced this on
>> other projects many times (including often forcing change of name) and I
>> don't understand why Subversion doesn't need to follow the same processes
>> and terminology. This should've been dealt with during incubation in fact.
>
> How does naming accomplish the goal of collaborative, consensus-based
> development? I thought that was why we were here. I hadn't heard that
> people and projects had to pay a "price" to be part of the Foundation.
Seconded.
Additionally, I'd like to note that I don't think that these "partial"
committers are so special, apart from the name. I think it goes
without saying that any new committer should restrict himself or
herself initially to only those parts, for which he or she was voted
in. For example, in the case of Commons I hesitate do commit anything
besides Fileupload even after years. The only difference I can see is
that Subversion emphasizes this fact (and possibly enforces it).
Jochen
--
I Am What I Am And That's All What I Yam (Popeye)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Subversion full/partial committer (was: Re: an experiment)
Posted by Greg Stein <gs...@gmail.com>.
On Wed, Aug 18, 2010 at 18:02, Sanjiva Weerawarana
<sa...@opensource.lk> wrote:
> On Tue, Aug 17, 2010 at 11:13 PM, Daniel Shahaf <d....@daniel.shahaf.name>wrote:
>> > When I saw this month's board report for Subversion, I was taken aback
>> > that the board is expected to follow the terminology used by only one
>> > project. Really? The board, which has used the same terms for 10++
>> > years, is now going to hear reports of full committers and partial
>> > committers? What do we do when another project comes in and uses yet
>> > different terms for the same concept? Do we now make a translation
>> > manual for everyone in Apache to use?
>> >
>>
>> Subversion *has* used these terms for a few years too. Should we just
>> stop using the terms we've used for N years?
>
> Yes .. that's part of the price of being in the ASF! We have forced this on
> other projects many times (including often forcing change of name) and I
> don't understand why Subversion doesn't need to follow the same processes
> and terminology. This should've been dealt with during incubation in fact.
How does naming accomplish the goal of collaborative, consensus-based
development? I thought that was why we were here. I hadn't heard that
people and projects had to pay a "price" to be part of the Foundation.
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Subversion full/partial committer (was: Re: an experiment)
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Tue, Aug 17, 2010 at 11:13 PM, Daniel Shahaf <d....@daniel.shahaf.name>wrote:
>
> > When I saw this month's board report for Subversion, I was taken aback
> > that the board is expected to follow the terminology used by only one
> > project. Really? The board, which has used the same terms for 10++
> > years, is now going to hear reports of full committers and partial
> > committers? What do we do when another project comes in and uses yet
> > different terms for the same concept? Do we now make a translation
> > manual for everyone in Apache to use?
> >
>
> Subversion *has* used these terms for a few years too. Should we just
> stop using the terms we've used for N years?
>
Yes .. that's part of the price of being in the ASF! We have forced this on
other projects many times (including often forcing change of name) and I
don't understand why Subversion doesn't need to follow the same processes
and terminology. This should've been dealt with during incubation in fact.
(Not sure why its copied to general@incubator since Subversion has graduated
... but I saw and commented because it is.)
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder, Director & Chief Scientist; Lanka Software Foundation;
http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Director; Sahana Software Foundation; http://www.sahanafoundation.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Blog: http://sanjiva.weerawarana.org/
Subversion full/partial committer (was: Re: an experiment)
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Craig L Russell wrote on Tue, Aug 17, 2010 at 09:42:18 -0700:
> One of the first things you learn in Apache is that there are (at least)
> three levels of involvement that community members can take:
> contributor, committer, PMC member. See "how it works, roles, etc. etc."
> on the Apache site.
>
> Now the subversion project comes in where these are not the commonly
> used terms. Instead, the terms for committer and PMC member are partial
> committer and full committer. That's fine for the established community,
> but the translation from committer -> partial committer and PMC member ->
> full committer needs to be done within the project, not within Apache.
>
Subversion doesn't have a concept of "has CTR commit access to the
entire tree, but is not a PMC member". (That would be something between
partial committer and full committer.) So, IIUC, it's more than
terminology difference; it's a semantic difference.
(In Subversion, adding to the PMC and granting tree-wide CTR commit
access have always been done simultaneously.)
> When I saw this month's board report for Subversion, I was taken aback
> that the board is expected to follow the terminology used by only one
> project. Really? The board, which has used the same terms for 10++
> years, is now going to hear reports of full committers and partial
> committers? What do we do when another project comes in and uses yet
> different terms for the same concept? Do we now make a translation
> manual for everyone in Apache to use?
>
Subversion *has* used these terms for a few years too. Should we just
stop using the terms we've used for N years?
<if 0>pun about svn folks being unable to forget their history</if>
> My $.02: if you want to talk about full and partial committers in the
> Apache community, there's more work to do so everyone gets on board with
> your terminology. Otherwise, communications will be enhanced if you keep
> full and partial committers to yourselves and translate to the commonly
> used Apache terms when dealing with the Apache community.
>
> And yes, I'd like to see the Subversion board report amended to remove
> references to full and partial.
>
Did you read the report?
In particular: lines 1710,1711,1717 of r24487 of the board agenda.
> Craig
>
> Craig L Russell
> Architect, Oracle
> http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@oracle.com
> P.S. A good JDO? O, Gasp!
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Craig L Russell <cr...@oracle.com>
> To: Incubator <ge...@incubator.apache.org>; Apache Board <bo...@apache.org>
> Sent: Tue, August 17, 2010 12:42:18 PM
> Subject: Re: an experiment
>
>
> On Aug 16, 2010, at 6:37 PM, Greg Stein wrote:
>
> > I certainly could have handled it better. But that thread is
> > *indicative* of the problem. We've pointed out a several now: two with
> > Subversion, one with OODT.
> >
> Since you've brought it up time and again, it's worth thrashing through. The
>kerfuffle about project roles was brought up by a member of the "peanut
>gallery" [sic] and I thought quite reasonably.
>
> Words matter. Definitions of terms matter. Communication is broken if I say a
>word that has one meaning for you and a different meaning for me. We end up
>talking about two different things and we think we're having a discussion but
>we're not.
>
> One of the first things you learn in Apache is that there are (at least) three
>levels of involvement that community members can take: contributor, committer,
>PMC member. See "how it works, roles, etc. etc." on the Apache site.
>
> Now the subversion project comes in where these are not the commonly used
>terms. Instead, the terms for committer and PMC member are partial committer
>and full committer. That's fine for the established community, but the
>translation from committer -> partial committer and PMC member -> full
>committer needs to be done within the project, not within Apache.
>
> When I saw this month's board report for Subversion, I was taken aback that
>the board is expected to follow the terminology used by only one project.
>Really? The board, which has used the same terms for 10++ years, is now going
>to hear reports of full committers and partial committers? What do we do when
>another project comes in and uses yet different terms for the same concept? Do
>we now make a translation manual for everyone in Apache to use?
>
> My $.02: if you want to talk about full and partial committers in the Apache
>community, there's more work to do so everyone gets on board with your
>terminology. Otherwise, communications will be enhanced if you keep full and
>partial committers to yourselves and translate to the commonly used Apache
>terms when dealing with the Apache community.
>
> And yes, I'd like to see the Subversion board report amended to remove
>references to full and partial.
FWIW, Craig's position here resonates with me more than
Justin's or Greg's. The "peanut-gallery-effect" is just
the well-intentioned effort by IPMC members to maintain
some semblance of uniformity when it comes to IPMC process,
policy, or terminology, and these folks shouldn't get
labeled as poisonous as a result of those activities.
What happened to Justin wrt OODT was someone trying to
enforce a silly procedural requirement. Directing the
complaints at the person who wrote the email is misguided,
when it is really the process that needs improvement.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Craig L Russell <cr...@oracle.com>.
On Aug 16, 2010, at 6:37 PM, Greg Stein wrote:
> I certainly could have handled it better. But that thread is
> *indicative* of the problem. We've pointed out a several now: two with
> Subversion, one with OODT.
>
Since you've brought it up time and again, it's worth thrashing
through. The kerfuffle about project roles was brought up by a member
of the "peanut gallery" [sic] and I thought quite reasonably.
Words matter. Definitions of terms matter. Communication is broken if
I say a word that has one meaning for you and a different meaning for
me. We end up talking about two different things and we think we're
having a discussion but we're not.
One of the first things you learn in Apache is that there are (at
least) three levels of involvement that community members can take:
contributor, committer, PMC member. See "how it works, roles, etc.
etc." on the Apache site.
Now the subversion project comes in where these are not the commonly
used terms. Instead, the terms for committer and PMC member are
partial committer and full committer. That's fine for the established
community, but the translation from committer -> partial committer and
PMC member -> full committer needs to be done within the project, not
within Apache.
When I saw this month's board report for Subversion, I was taken aback
that the board is expected to follow the terminology used by only one
project. Really? The board, which has used the same terms for 10++
years, is now going to hear reports of full committers and partial
committers? What do we do when another project comes in and uses yet
different terms for the same concept? Do we now make a translation
manual for everyone in Apache to use?
My $.02: if you want to talk about full and partial committers in the
Apache community, there's more work to do so everyone gets on board
with your terminology. Otherwise, communications will be enhanced if
you keep full and partial committers to yourselves and translate to
the commonly used Apache terms when dealing with the Apache community.
And yes, I'd like to see the Subversion board report amended to remove
references to full and partial.
Craig
Craig L Russell
Architect, Oracle
http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@oracle.com
P.S. A good JDO? O, Gasp!
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: an experiment
Posted by "Noel J. Bergman" <no...@devtech.com>.
Greg Stein wrote:
> > I read that thread, and as I commented on private@, I thought that it
could
> > have been handled better.
> I certainly could have handled it better.
I didn't mean by YOU. See my reply on private@ before jumping to that
conclusion.
> But that thread is *indicative* of the problem. We've pointed out a
several now: two with
> Subversion, one with OODT.
OK. So let's address it.
> > Did you miss the several points where I said that if someone isn't
participating
> > in a given project then unless they have one of a few issues of
substance they
> > should either actively become part of the community or butt out?
> Say it all you want, but that isn't how people operate here. Simple fact.
> If you want to fix it, then *DO* something rather than speak about it.
Fine. What would you suggest? And that includes your proposal, which I do
consider interesting. But consider, too, Leif's issue that their biggest
problem was the opposite: *getting* the 3 necessary votes. So lets resolve
this in a more general fashion than TLP level partitioning.
> > And did you miss my request to the Board for their input on the issue of
> > whether or not the PMC has to vote on new Committers? Claiming that I'm
not
> > listening or open is, frankly, insulting.
> I saw that, and I saw Joe's request that you mischaracterized him, and
> then you brushed him off.
I didn't brush Joe off. I went back at the same time and replied on this
list in the related thread, which is where the actual details had been
posted, rather than in the abstract on board@. See my reply to CLR for
details.
>>> The Incubator is a broken process. Everybody hates it. Everybody wants
to
>>> get out of it.
>> That is not the message that we get from most participants, but if that
is
>> the case, then let's fix it.
> Who is "we"?? I'm part of the IPMC, so I'm part of that "we". Most of
> the feedback that I ever hear is not supportive.
We is the PMC as a whole, general@, private@. But, sure, let's follow
through on your suggestion and run a poll. Lets find out if things are
going well, what the problems are, how widespread or isolated they are, and
make the effort to resolve them. As I said ...
> > Let's be concrete and constructive, identify the specific problems
> > and address them.
> I've already told you. Disinterested third parties touting rules and
> patterns that were NOT part of the Apache Way, but were most
> definitely anti-Subversion-community. Certainly they had some
> *commonality* around Apache projects, but were in no way a required
> part of a collaborative, community-driven development process. They
> were just "different"
> The Incubator supports the concept of random drive-bys
> from disinterested third parties.
A bit harsh to call them disinterested. :-)
OK, to be clear, what I'm reading from you, Justin and others, is that this
is *the* problem you want to resolve.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Greg Stein <gs...@gmail.com>.
On Mon, Aug 16, 2010 at 21:30, Noel J. Bergman <no...@devtech.com> wrote:
> Greg Stein wrote:
>...
>> but the busy-bodies and rules pedants got all in our face.
>
> I read that thread, and as I commented on private@, I thought that it could
> have been handled better.
I certainly could have handled it better. But that thread is
*indicative* of the problem. We've pointed out a several now: two with
Subversion, one with OODT.
If that isn't enough for you, then you need to wake up to the pattern.
>> Every message that I've seen from you today, Noel, is "gee. everything
>> is operating just fine. just like it should. oversight is everything,
>> and we need to do that, so I'm not going to listen to any suggestion
>> of fixing anything or restructuring anything."
>
> Then you need to re-read them. Did you miss the several points where I said
> that if someone isn't participating in a given project then unless they have
> one of a few issues of substance they should either actively become part of
> the community or butt out?
Say it all you want, but that isn't how people operate here. Simple fact.
If you want to fix it, then *DO* something rather than speak about it.
> And did you miss my request to the Board for their input on the issue of
> whether or not the PMC has to vote on new Committers? Claiming that I'm not
> listening or open is, frankly, insulting.
I saw that, and I saw Joe's request that you mischaracterized him, and
then you brushed him off.
Oh yes, I *am* tracking all this. Very closely.
>> The Incubator is a broken process. Everybody hates it. Everybody wants to
> get out of it.
>
> That is not the message that we get from most participants, but if that is
> the case, then let's fix it.
Who is "we"?? I'm part of the IPMC, so I'm part of that "we". Most of
the feedback that I ever hear is not supportive.
Might be interesting to run a poll. Get some real numbers. "Have you
been through Incubation? Was it a positive experience?"
>> Subversion was fortunate in that we had enough support to bully our way
> through, to route
>> around damage
>
> Such as? Let's be concrete and constructive, identify the specific problems
> and address them.
I've already told you. Disinterested third parties touting rules and
patterns that were NOT part of the Apache Way, but were most
definitely anti-Subversion-community. Certainly they had some
*commonality* around Apache projects, but were in no way a required
part of a collaborative, community-driven development process. They
were just "different", so these third parties got in our face. Because
they *could*. The Incubator supports the concept of random drive-bys
from disinterested third parties.
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Ross Gardler <rg...@apache.org>.
On 17/08/2010 05:32, Justin Erenkrantz wrote:
> On Mon, Aug 16, 2010 at 6:26 PM, Ross Gardler<rg...@apache.org> wrote:
>> I've already decided that I'm going to have to recruit a number of key
>> mentors to help me protect the project during incubation.
>
> Historically, I think there are two classes of podlings:
> - one which has a self-governing community and just needs to get
> indoctrinated in the "Apache Way" (SpamAssassin, Subversion, etc.)
> - one which doesn't have a self-governing community (thrift, traffic
> server, etc.)
>
> Perhaps Greg is on to something with having us split up the process.
> It's always bugged me that there were two different classes that we
> tried to shoehorn into one process.
>
> Accordingly, in these two models, the role of the mentor is very different:
> - self-governing community: making sure they get introduced to the
> right people and understand the minimum requirements; but, really,
> they shouldn't interfere with the actual day-to-day governance.
> - no self-governing community: helping the developers understand what
> it means to self-govern.
Yes, I agree.
I'm not, for example, interested in Wookie moving to either of the
current proposals. Our mentors are providing enough oversight and the
community is not unhealthy, it just needs to learn to bring even more
into the open. This takes time, experience and exposure. We can't brow
beat people into doing this, we just have to give them time to find the
right balance and attract new committers.
On the other hand the next project I hope to bring in already has a
vibrant community, it's just struggling to find diversity. The neutral
ground and legal oversight the ASF provides is likely to help
considerably here.
I don't agree that the incubator is broken, only that it can be improved.
Ross
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Eric Johnson <er...@tibco.com>.
On 08/16/2010 09:32 PM, Justin Erenkrantz wrote:
> On Mon, Aug 16, 2010 at 6:26 PM, Ross Gardler <rg...@apache.org> wrote:
>> I've already decided that I'm going to have to recruit a number of key
>> mentors to help me protect the project during incubation.
> Historically, I think there are two classes of podlings:
> - one which has a self-governing community and just needs to get
> indoctrinated in the "Apache Way" (SpamAssassin, Subversion, etc.)
> - one which doesn't have a self-governing community (thrift, traffic
> server, etc.)
>
> Perhaps Greg is on to something with having us split up the process.
> It's always bugged me that there were two different classes that we
> tried to shoehorn into one process.
>
> Accordingly, in these two models, the role of the mentor is very different:
> - self-governing community: making sure they get introduced to the
> right people and understand the minimum requirements; but, really,
> they shouldn't interfere with the actual day-to-day governance.
> - no self-governing community: helping the developers understand what
> it means to self-govern.
As a non-member, with cursory interaction with Apache over a very long
term (some very small contributions to some projects), and a very recent
interest in getting a project into incubation at Apache, this problem
looks very different to me.
Supposition: Involvement in projects will always follow a power-law for
# of interested parties. Even within Apache, some projects will
dominate with a large number of interested parties, and the rest will
eventually taper off into a "long-tail."
Supposition: Due to potential "bit-rot", Apache wants to make sure that
projects have an ongoing commitment over time. Otherwise, projects will
start out, gather some interest, and then people will drift off an do
something else. Unchanged left-over code will "bit-rot" - as the
language/compilers and supporting libraries for the code in question
change, the code that works on top of those libraries/languages needs to
stay current. Security problems might crop up in the most obscure
places, and need to be addressed by an active community.
Consequence: Apache wants to make sure that projects sustain a
commitment over time. Incubation is the proxy for judging this question
- if a project makes it through incubation, presumably it will sustain
itself. The proxies are indirect data points, like three independent
committers, filing reports on time, voting out a release, nailing down
licensing issues.
This brings me to Justin's analysis. The distinction that Justin makes
above doesn't seem quite right to me. To me, it isn't a question of
"self-governing" - Apache should be able to clearly lay out a process,
deadlines & guidelines - and sure as heck, people who write down rules
for how a computer works ought to be able to follow rules/processes for
people. If they cannot, they don't belong at Apache, as they cannot
self-manage. Lay out the rules, however odd they might be, and as long
as they're clearly communicated, and there are people who are familiar
with the rules to guide newbies along, you'll get people who can
self-manage.
For the projects that fall on the high end of the power-law spectrum,
following the rules isn't a problem. And I suspect, actually, it isn't
really for projects on the low-end of the spectrum - except that they're
simply unfamiliar just like everyone else, and might need more
training/attention/mentoring, because they're less likely to have the
experts from Apache already deeply involved. Putting my former
management hat on, (and oversimplifying dramatically) this seems like a
training/education problem, and you solve it with a bunch of techniques
- training sessions, "quizzes", materials that everyone is expected to
master, presentations/interactions at conferences, etc. This probably
isn't all that theoretically hard, it just needs a little bit of
constant attention, and needs to be applied to all newcomers. What
makes it practically difficult is that it isn't interesting to people
who want to right code, and it is actually hard to do well, as the best
materials take the viewpoint of a newcomer.
I see a particular problem screaming out of the incubation reports for
many of projects in incubation (and the problem we're having with our
proposal). How to attract and sustain attention from people already
involved with Apache, and attracting committers from everywhere? As I
see it, this almost by definition falls out of the "power-law" curve I
mentioned above. There will be some percentage of projects (1/2,
1/3rd?) that struggle to meet the criteria laid out. Self-governing
*shouldn't* be a problem, because people should be told up front -
"understand these materials, then see if you really want to join the
party." What will naturally be a problem, though is that the bottom
half or bottom third of the incubating projects need to attract and
sustain attention. Seems like developing and sustaining that attention
really should be the role of the incubator - training on the rules ought
to be an incidental piece.
Anyway, coming back to Justin's division, I see three or four chunks
instead of his two:
- high visibility projects. Really no doubt that they have commitment
over time. Just need training on rules. Switch from incubation to full
project should involve as few rule changes as possible, so as to
minimize retraining.
- near-high projects - like high-visibility projects, but run the risk
of having "spoilers" that can sap the community, and other things that
can derail the involvement. How do you protect against that?
- middling projects - can get lost in mechanics - like simply delivering
a release. Can be killed by a small amount of community-sapping
behavior. Need prodding from the community to release early, release
often, and sustain high standards. Need some help gathering interest,
and need to fend off community sappers.
- low visibility projects - like middling projects, but need lots of
help with gathering interest. Need prodding to spend less time coding,
and more time community building - reaching out to other Apache
projects, contacting and engaging with similar open-source projects not
at Apache, perhaps working with people in academia, blogging, etc.
My point - a one-size fits all approach is effectively doomed to cause
some unnecessary failures. That doesn't mean that you cannot have one
set of rules for what must be done, but it does mean that how those
rules are applied is effectively different. Put differently, does the
incubator aim to help projects succeed at Apache once accepted into
incubation, or does the incubator simply let chips fall where they may,
and let interesting projects die?
Maybe I'm just a naive newbie to look at it this way, but I thought I'd
throw out my $0.02.
-Eric.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Mon, Aug 16, 2010 at 6:26 PM, Ross Gardler <rg...@apache.org> wrote:
> I've already decided that I'm going to have to recruit a number of key
> mentors to help me protect the project during incubation.
Historically, I think there are two classes of podlings:
- one which has a self-governing community and just needs to get
indoctrinated in the "Apache Way" (SpamAssassin, Subversion, etc.)
- one which doesn't have a self-governing community (thrift, traffic
server, etc.)
Perhaps Greg is on to something with having us split up the process.
It's always bugged me that there were two different classes that we
tried to shoehorn into one process.
Accordingly, in these two models, the role of the mentor is very different:
- self-governing community: making sure they get introduced to the
right people and understand the minimum requirements; but, really,
they shouldn't interfere with the actual day-to-day governance.
- no self-governing community: helping the developers understand what
it means to self-govern.
For an existing self-governing case, I would ideally like it so that
the mentors were purely advisory - the ultimate responsibility lies
with the community - as it must, or we're teaching them the wrong
things. I don't know (or really care) how that reconciles with any
corporate structures - but I'm sure we can certainly get creative in
solving this.
In Subversion, the mentors we had were already full committers and had
earned their merit within the community. So, when Greg, Dan, Sander,
or I said something, the rest of the community knew we weren't
crackpots. Based on Ross's description of the community, it doesn't
sound like there's enough coverage to get a 3 member "minimum" - but,
the very fact that a community can decide to come to Apache is itself
a form of self-governance. So...it's a touch circular, but I go back
to thinking that a purely advisory role is right for any mentors
coming in when there's self-governance already existing.
Considering Thrift's situation in trying to bootstrap their
self-governance, I can totally see why Joe likes that particular tweak
and why that might be sufficient for their case.
I don't have any clear answers, but, I'd really like to continue
exploring where this thought takes us as I think there's a solution
here that can ease the pain somewhat. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Ross Gardler <rg...@apache.org>.
On 17/08/2010 02:05, Greg Stein wrote:
> On Mon, Aug 16, 2010 at 16:47, Noel J. Bergman<no...@devtech.com> wrote:
...
> Your head is in the sand. The Incubator is a broken process. Everybody
> hates it. Everybody wants to get out of it. Subversion was fortunate
> in that we had enough support to bully our way through, to route
> around damage, and to check everything off the list rapidly. Whoever
> said it before: if we *didn't* have that fortunate fact behind us,
> then our approach to the ASF would have been very very different.
I have to agree. I am currently working with a very large project that
is interested in coming into the incubator. There are two major issues
for me to address:
One is getting the lawyers from the originating company to agree to the
legal sign-off - nothing new there.
The other is getting the project through the incubator in a reasonable
time so that its large number of users don't get the jitters and switch
to an alternative platform.
The project genuinely tries to operate in an ASF like manner but has
some inherent problems that are rooted in the fact that 75%+ of
committers all being part of a single company and all lacking experience
of ASF style development models. Consequently, some working practices
will need to be changed, but the committers are aware of the changes
required and willing to do the work.
Unlike Subversion there are no pre-existing members on the commit list
and thus noone to shelter the project team from the peanut gallery here
in general@.
I've already decided that I'm going to have to recruit a number of key
mentors to help me protect the project during incubation.
For some reason that never occurred to me as being kind of anti-apache.
Aren't we a flat organisation? It really shouldn't matter who the
mentors are as long as they are members, yet I had subconsciously
decided that it did matter.
For this reason I have to agree that the Incubator process is not coping
well with the large numbers of interested bystanders we have on the
IPMC. Oversight is good, but we don't need the oversight of the peanut
gallery.
Kudos to those trying to solve this problem without completely breaking
up an otherwise healthy incubation process.
Ross
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Kalle Korhonen <ka...@gmail.com>.
On Mon, Aug 16, 2010 at 6:05 PM, Greg Stein <gs...@gmail.com> wrote:
> Your head is in the sand. The Incubator is a broken process. Everybody
> hates it. Everybody wants to get out of it. Subversion was fortunate
> in that we had enough support to bully our way through, to route
> around damage, and to check everything off the list rapidly. Whoever
> said it before: if we *didn't* have that fortunate fact behind us,
> then our approach to the ASF would have been very very different.
Perhaps it's useful to have some other experiences heard from those
who are currently going through the incubation process. Apache Shiro
is on the verge of graduation (voting going on right now), I'm a new
member of Apache (i.e. not one of the people in the original project
proposal) and I don't see much wrong in the current process. We have a
small PPMC and there have been a few cases where we've needed to prod
the interest of the mentors to gain enough votes but I don't think
there's anything broken in that. For the more important votes, we've
gotten some -1s from some Apache members we've never heard of before,
but negatives need to be and are justified and are typically given for
reasons we as new members had missed or hadn't considered at all. I
recognize there's a lot of history before our project so I for would
give a benefit of doubt for "any random drive-bys from disinterested
third parties" :) I mean, after all, the incubator process is about
teaching the "Apache way" and whatever it is, it's probably not about
changing the process to your liking. If I have to beg for a few +1s or
reason my way out of -1s, I'll be happy to do that, and hopefully
demonstrate our willingness and ability to self govern along way.
Kalle
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Leif Hedstrom <zw...@apache.org>.
On 08/16/2010 07:30 PM, Noel J. Bergman wrote:
>
> That is not the message that we get from most participants, but if that is
> the case, then let's fix it.
As I mentioned in a previous post, the main problem we (ATS) had was to
get enough binding votes. Even from the IPMC we failed one release vote
due to lack of votes (there were no -1's, just not enough +1's), and
several times did I have to beg to get votes for a committer addition
(all our committer votes had to be voted on in the IPMC, to get binding
votes). We were however extremely fortunate to have the active support
of several Apache old-timers, who stepped up and helped us push through
the process, and they were a huge reason why we could graduate as
quickly as we did.
That other thing that surprised me was that there was no "exit review"
process out of incubation. Meaning, I would have expected each
graduating project to provide some sort of feedback or evaluation to
the IPMC, to help improve the incubation process incrementally. Yes, I
know we can all just post to general@ (or private@), but it seems that
having a more official exist review of the project and its incubation
experience would be helpful. This would give feedback to the IPMC
(Sponsor), as well as Mentors and Champion, about what worked, and
what didn't.
-- Leif
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: an experiment
Posted by "Noel J. Bergman" <no...@devtech.com>.
Greg Stein wrote:
> Noel J. Bergman <no...@devtech.com> wrote:
> > <<shrug>> There are other instances of such things, such as httpd-docs
> > (IIUC), and I don't see a problem with it where a project feels it makes
> > sense.
> Our project thought it did make sense
Fine, and I'd agree with you.
> but the busy-bodies and rules pedants got all in our face.
I read that thread, and as I commented on private@, I thought that it could
have been handled better.
> Every message that I've seen from you today, Noel, is "gee. everything
> is operating just fine. just like it should. oversight is everything,
> and we need to do that, so I'm not going to listen to any suggestion
> of fixing anything or restructuring anything."
Then you need to re-read them. Did you miss the several points where I said
that if someone isn't participating in a given project then unless they have
one of a few issues of substance they should either actively become part of
the community or butt out?
And did you miss my request to the Board for their input on the issue of
whether or not the PMC has to vote on new Committers? Claiming that I'm not
listening or open is, frankly, insulting.
> The Incubator is a broken process. Everybody hates it. Everybody wants to
get out of it.
That is not the message that we get from most participants, but if that is
the case, then let's fix it.
> Subversion was fortunate in that we had enough support to bully our way
through, to route
> around damage
Such as? Let's be concrete and constructive, identify the specific problems
and address them.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Greg Stein <gs...@gmail.com>.
On Mon, Aug 16, 2010 at 16:47, Noel J. Bergman <no...@devtech.com> wrote:
> Kevan Miller wrote:
>
>> IIRC, the issue involved the notion of "partial committers" in subversion
>> There were objections over the notion of "partial committers", not about
> the individual.
>
> <<shrug>> There are other instances of such things, such as httpd-docs
> (IIUC), and I don't see a problem with it where a project feels it makes
> sense.
Our project thought it did make sense, but the busy-bodies and rules
pedants got all in our face.
Every message that I've seen from you today, Noel, is "gee. everything
is operating just fine. just like it should. oversight is everything,
and we need to do that, so I'm not going to listen to any suggestion
of fixing anything or restructuring anything."
Every. Message.
Your head is in the sand. The Incubator is a broken process. Everybody
hates it. Everybody wants to get out of it. Subversion was fortunate
in that we had enough support to bully our way through, to route
around damage, and to check everything off the list rapidly. Whoever
said it before: if we *didn't* have that fortunate fact behind us,
then our approach to the ASF would have been very very different.
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: an experiment
Posted by "Noel J. Bergman" <no...@devtech.com>.
Kevan Miller wrote:
> IIRC, the issue involved the notion of "partial committers" in subversion
> There were objections over the notion of "partial committers", not about
the individual.
<<shrug>> There are other instances of such things, such as httpd-docs
(IIUC), and I don't see a problem with it where a project feels it makes
sense.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Kevan Miller <ke...@gmail.com>.
On Aug 16, 2010, at 2:52 PM, Noel J. Bergman wrote:
> Presumably there was no valid basis for the -1? Sucks, but Joe's proposal
> doesn't change the fact that any PMC Member can still vote on any project.
> The ASF does not have subprojects, there is only one PMC. We have gone
> through this with Jakarta and XML over those issues.
IIRC, the issue involved the notion of "partial committers" in subversion -- http://subversion.apache.org/docs/community-guide/roles.html#committers There were objections over the notion of "partial committers", not about the individual.
I don't view subversion as a particularly good motivating example of why the Incubator is or is not broken. Subversion was unique from the very beginning...
In general, I agree with in Noel... Would add that IMO, incubator oversight has helped release processes (and general foundation knowledge) for many projects, not just those who have been through incubation...
--kevan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: an experiment
Posted by "Noel J. Bergman" <no...@devtech.com>.
Justin Erenkrantz wrote:
> a quick recap.
> an Incubator PMC member who was never involved in [the] community jumped
in
> the middle of a committer vote to vote -1. Greg wrote a cranky email
telling
> him to go away. Most of the committers in SVN were taken aback by the
behavior.
> "Who is this person? Why do they get to vote -1? "
Presumably there was no valid basis for the -1? Sucks, but Joe's proposal
doesn't change the fact that any PMC Member can still vote on any project.
The ASF does not have subprojects, there is only one PMC. We have gone
through this with Jakarta and XML over those issues.
> For OODT, we voted on a committer - but forgot to do the
> "pre-acknowledgement" and Chris got taken out to the
> woodshed by some members because we sent the "ack" *after*
> the vote. Chris didn't go cranky, but I would have.
Perhaps we need to remind people that mistakes happen -- ESPECIALLY in the
Incubator -- and we need to extend courtesy and assistence, not
back-of-the-woodshed beatings. And, as I just noted to Chris, I am all for
any streamlining that we can do, so long as it preserves PMC oversight.
> > And given that Subversion clearly (should have) had more
> > than 3 PMC members, how did it impact?
> after graduation, in Subversion, Greg has had to constantly reinforce that
> the Subversion PMC gets to make the decisions in the project and stop
looking
> for others to set policy - as that's the (false) precedent set by the
Incubator.
I see what you are saying, but the issue is that ASF project policy is set
by its PMC, and until an Incubator project graduates, that PMC is the
Incubator PMC. But we do try to allow the project a lot of leeway to
self-govern, which is why the PPMC exists in the first place. And I'm
curious as to why Subversion folks got into a habit of looking elsewhere,
since the Subversion project pretty much *did* self-govern (having plenty of
PMC Members and ASF Members on the project) during its short Incubation.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Mon, Aug 16, 2010 at 11:22 AM, Noel J. Bergman <no...@devtech.com> wrote:
> What happened?
It's all in the archives, but a quick recap.
For Subversion, an Incubator PMC member who was never involved in the
SVN community jumped in the middle of a committer vote to vote -1.
Greg wrote a cranky email telling him to go away. Most of the
committers in SVN were taken aback by the behavior. "Who is this
person? Why do they get to vote -1? "
For OODT, we voted on a committer - but forgot to do the
"pre-acknowledgement" and Chris got taken out to the woodshed by some
members because we sent the "ack" *after* the vote. Chris didn't go
cranky, but I would have. (I was in the middle of moving when that
happened - even then I threw away a few cranky emails...)
> And given that Subversion clearly (should have) had more
> than 3 PMC members, how did it impact?
Even after graduation, in Subversion, Greg has had to constantly
reinforce that the Subversion PMC gets to make the decisions in the
project and stop looking for others to set policy - as that's the
(false) precedent set by the Incubator. The behavior of the Incubator
PMC can set a bad tone - and those of us mentoring have often had to
take proactive efforts to undo the damage. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Benson Margulies <bi...@gmail.com>.
i am not confused:-) the entire incubator is a 'walled sandbox'. if projects can grant streamlined karma to sandbox branches to students, why not let podlings add committers?
On Aug 16, 2010, at 2:23 PM, Daniel Kulp <dk...@apache.org> wrote:
> On Monday 16 August 2010 2:15:32 pm Luciano Resende wrote:
>> On Mon, Aug 16, 2010 at 10:57 AM, Benson Margulies
>>
>> <bi...@gmail.com> wrote:
>>> On committers there is a legal / procedural clarification called for.
>>> Perhaps I'm just dense, but I got the strong impression from the recent
>>> email at members@ that there was much more flexibility possible with
>>> committer status than with releases -- that the iPMC could indeed make a
>>> one-time, blanket, decision, that PPMC votes were sufficient for
>>> committer status. To cite an example to support my position, I'm pretty
>>> sure that GSOC students get commit privileges without formal PMC votes.
>>
>> Could you clarify on what do you mean by your statement around GSoC
>> Students. GSoC students are and should be tread as any other
>> contributors to a project and should earn committer karma via regular
>> channels (discuss/vote/etc).
>
> I think he's confusing getting commit karma on a project and getting an Apache
> account that would allow commit to a sandbox or similar. For some projects,
> we had the students submit a ICLA and we had accounts created that gave them a
> walled off sandbox to commit their work into rather than have them creating
> forks or something off at GitHub or similar. They don't have project commit
> karma to commit to trunk or branches or anything, just a very walled off
> sandbox.
>
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Daniel Kulp <dk...@apache.org>.
On Monday 16 August 2010 2:15:32 pm Luciano Resende wrote:
> On Mon, Aug 16, 2010 at 10:57 AM, Benson Margulies
>
> <bi...@gmail.com> wrote:
> > On committers there is a legal / procedural clarification called for.
> > Perhaps I'm just dense, but I got the strong impression from the recent
> > email at members@ that there was much more flexibility possible with
> > committer status than with releases -- that the iPMC could indeed make a
> > one-time, blanket, decision, that PPMC votes were sufficient for
> > committer status. To cite an example to support my position, I'm pretty
> > sure that GSOC students get commit privileges without formal PMC votes.
>
> Could you clarify on what do you mean by your statement around GSoC
> Students. GSoC students are and should be tread as any other
> contributors to a project and should earn committer karma via regular
> channels (discuss/vote/etc).
I think he's confusing getting commit karma on a project and getting an Apache
account that would allow commit to a sandbox or similar. For some projects,
we had the students submit a ICLA and we had accounts created that gave them a
walled off sandbox to commit their work into rather than have them creating
forks or something off at GitHub or similar. They don't have project commit
karma to commit to trunk or branches or anything, just a very walled off
sandbox.
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Greg Stein <gs...@gmail.com>.
On Mon, Aug 16, 2010 at 13:57, Benson Margulies <bi...@gmail.com> wrote:
>...
> On committers there is a legal / procedural clarification called for.
> Perhaps I'm just dense, but I got the strong impression from the recent
> email at members@ that there was much more flexibility possible with
> committer status than with releases -- that the iPMC could indeed make a
> one-time, blanket, decision, that PPMC votes were sufficient for committer
> status. To cite an example to support my position, I'm pretty sure that GSOC
> students get commit privileges without formal PMC votes.
>
> However, if I am dense, and if the foundation requirements do require a real
> PMC vote for committer access, then the idea of my first paragraph would
> apply.
For reference, any Subversion PMC member can grant (limited) commit
status to another individual. We believe that if somebody with
long-term involvement in the project (on the PMC) feels that another
can do some good work, then they are entitled to make that happen. The
new committer can *only* commit into a specific area (like a branch,
or a specific directory), so we aren't scared for the project. We can
always revert the commits and/or remove commit rights. The commits get
reviewed, so we don't feel there are issues around submarine code
either.
Getting onto the PMC itself is a full vote, however. And those account
requests *do* have to come from me, as the VP of Subversion (a rule
from root@, tho Joe has said he is relaxing that a bit as long as the
private@ list is cc'd).
But your point is true: committership is a local, PMC decision. They
can apply easy or strict rules. The IPMC could certainly delegate
these decisions to the PPMCs.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Luciano Resende <lu...@gmail.com>.
On Mon, Aug 16, 2010 at 10:57 AM, Benson Margulies
<bi...@gmail.com> wrote:
> On committers there is a legal / procedural clarification called for.
> Perhaps I'm just dense, but I got the strong impression from the recent
> email at members@ that there was much more flexibility possible with
> committer status than with releases -- that the iPMC could indeed make a
> one-time, blanket, decision, that PPMC votes were sufficient for committer
> status. To cite an example to support my position, I'm pretty sure that GSOC
> students get commit privileges without formal PMC votes.
>
Could you clarify on what do you mean by your statement around GSoC
Students. GSoC students are and should be tread as any other
contributors to a project and should earn committer karma via regular
channels (discuss/vote/etc).
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Benson Margulies <bi...@gmail.com>.
There is some obvious compromises opportunity here. On releases, the iPMC
could decide, by internal convention, to let the involved three mentors
(when there are three involved members) be the relevant voice. iPMC members
could pledge to defer to the involved mentors unless they feel that there is
some overwhelming reason to vote -1.
On committers there is a legal / procedural clarification called for.
Perhaps I'm just dense, but I got the strong impression from the recent
email at members@ that there was much more flexibility possible with
committer status than with releases -- that the iPMC could indeed make a
one-time, blanket, decision, that PPMC votes were sufficient for committer
status. To cite an example to support my position, I'm pretty sure that GSOC
students get commit privileges without formal PMC votes.
However, if I am dense, and if the foundation requirements do require a real
PMC vote for committer access, then the idea of my first paragraph would
apply.
On Mon, Aug 16, 2010 at 1:43 PM, Justin Erenkrantz <ju...@erenkrantz.com>wrote:
> On Mon, Aug 16, 2010 at 10:37 AM, Noel J. Bergman <no...@devtech.com>
> wrote:
> > Where are you seeing this "over-reach" problem to which you refer? I
> have
> > heard of a few isolated incidents, and those can be addressed. But by
> far
> > and way, the biggest complaint is LACK of involvement, e.g.,
> ...
> > And most cases of PMC members getting involved in projects of which they
> > aren't a Mentor have been with respect to release packaging, where the
> > involvement has generally been valid and valuable, even if bothersome to
> > those whose packages weren't quite up to snuff.
> >
> > But, seriously, if there is systemic overreaching, lets address *that*
> > issue.
>
> The cases of "overreaching" in Subversion and OODT related to adding
> new committers - not releases. So, I'm definitely in favor of Joe's
> proposal to let the PPMC have control over who gets to be in the
> community. -- justin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
RE: an experiment
Posted by "Noel J. Bergman" <no...@devtech.com>.
Justin Erenkrantz wrote:
> > But, seriously, if there is systemic overreaching, lets address *that*
> > issue.
> The cases of "overreaching" in Subversion and OODT related to adding
> new committers - not releases.
What happened? And given that Subversion clearly (should have) had more
than 3 PMC members, how did it impact?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Mon, Aug 16, 2010 at 10:37 AM, Noel J. Bergman <no...@devtech.com> wrote:
> Where are you seeing this "over-reach" problem to which you refer? I have
> heard of a few isolated incidents, and those can be addressed. But by far
> and way, the biggest complaint is LACK of involvement, e.g.,
...
> And most cases of PMC members getting involved in projects of which they
> aren't a Mentor have been with respect to release packaging, where the
> involvement has generally been valid and valuable, even if bothersome to
> those whose packages weren't quite up to snuff.
>
> But, seriously, if there is systemic overreaching, lets address *that*
> issue.
The cases of "overreaching" in Subversion and OODT related to adding
new committers - not releases. So, I'm definitely in favor of Joe's
proposal to let the PPMC have control over who gets to be in the
community. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Mon, Aug 16, 2010 at 10:06 AM, Joe Schaefer <jo...@yahoo.com> wrote:
> Perhaps that's true for the projects you work on, but it certainly
> isn't true of Thrift, where mentorship has been a revolving door
> for years.
True. I've never been a big fan of requiring 3 mentors - as I think
certain personalities can do the teaching by themselves. However, if
accepting that minimum requirement resolves the over-reach by others,
I'd accept that tradeoff. Yes, it might kill off Thrift, but harming
podlings with 3+ active mentors is even worse behavior. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Justin Erenkrantz <ju...@erenkrantz.com>
> To: general@incubator.apache.org
> Sent: Mon, August 16, 2010 12:45:17 PM
> Subject: Re: an experiment
>
> On Mon, Aug 16, 2010 at 9:36 AM, Noel J. Bergman <no...@devtech.com> wrote:
> > And if the Mentors aren't being active, voting, etc., then *that* is what
> > needs to be addressed.
>
> As I've repeatedly stated before (here and elsewhere), in the podlings
> I've been recently involved with, having three mentors isn't the
> issue.
Perhaps that's true for the projects you work on, but it certainly
isn't true of Thrift, where mentorship has been a revolving door
for years.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: an experiment
Posted by "Noel J. Bergman" <no...@devtech.com>.
Justin Erenkrantz wrote:
> > We have one of the largest PMCs in the ASF.
> I view this as potentially the crux of the problem - people who aren't
> stakeholders in the community shouldn't have a say. Right now, they
> feel they do. So, if we want to mandate at least 3 mentors - fine,
> but that must come at the cost of telling the rest of the IPMC to go
> away - unless they actively contribute to the community and earn
> merit...of course.
Where are you seeing this "over-reach" problem to which you refer? I have
heard of a few isolated incidents, and those can be addressed. But by far
and way, the biggest complaint is LACK of involvement, e.g.,
> Lack of binding votes was seen as the main "problem" for Traffic Server
> during incubation, other than that, I think the process mostly "just
> works" as it is.
And most cases of PMC members getting involved in projects of which they
aren't a Mentor have been with respect to release packaging, where the
involvement has generally been valid and valuable, even if bothersome to
those whose packages weren't quite up to snuff.
But, seriously, if there is systemic overreaching, lets address *that*
issue.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Noel,
>> I guess that's what I take exception to, I think the PPMC _should_ have
>> standing.
>
> As per http://www.apache.org/foundation/bylaws.html#6.3, the defined
> governing entity is the Project Management Committee, better known as the
> PMC. And while the text does say that the PMC Chair "shall establish rules
> and procedures for the day to day management of project(s) for which the
> committee is responsible", it is the accepted practice of the ASF that the
> PMC makes all decisions.
Welp, hopefully we get clarification on this and whether or not it can be a
PMC (or PMC chair's) call on the *who* gets to make the decisions.
One way forward would be if the IPMC consisted of the set of active
contributors to a podling (including mentors + podling committers), then
we're really saying the same thing. This is one of the things I've heard
that's up for discussion and I for one am in favor of it.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: an experiment
Posted by "Noel J. Bergman" <no...@devtech.com>.
Chris A Mattmann wrote:
> > Well, that's sufficient, Chris. There should be no "nice to have"
aspect.
> > The only requirement is that the PMC has the ability to oversee. If we
can
> > streamline that process, great.
> Yeah, I guess to me the PPMC mentors should be fine to oversee without
> double checking with the IPMC.
They should be fine, but the PMC still needs to have the opportunity to
provide oversight.
> The podling mentors represent the IPMC in my mind and should be its
shepherds,
> not those other IPMC folks who aren't participating in the day to day of
the podling.
People not participating should generally stay out of it unless necessary.
Necessary might be:
- not enough +1 votes, so please help
- improper release packaging
- something really out of whack
Otherwise, get involved or butt out. :-) But until the project graduates,
PMC members *can* have a say. Don't like it? Graduate faster! :-D
>> The problem is that the PPMC has no standing. I keep telling people to
stop
>> using the term IPMC. It is the Incubator PMC. The terms IPMC and PPMC
make
>> them look somehow equivalent.
> I guess that's what I take exception to, I think the PPMC _should_ have
> standing.
As per http://www.apache.org/foundation/bylaws.html#6.3, the defined
governing entity is the Project Management Committee, better known as the
PMC. And while the text does say that the PMC Chair "shall establish rules
and procedures for the day to day management of project(s) for which the
committee is responsible", it is the accepted practice of the ASF that the
PMC makes all decisions.
> to me, podling mentors = IPMC* oversight, so if 3+ mentors approve, then
that should be it IMHO.
I'd say that 3+ Mentors *and* lazy consensus (which basically just means a
notice requirement) of the PMC is sufficient.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Noel,
Thanks for your reply. Comments below:
>> From my point of view, it would be nice for podlings with active mentors
>> to be able to guide their own decisions, especially if there are 3 active
>> mentors and they approve. For example in our case in OODT, we can achieve
>> consensus and obtain much of the necessary VOTEs and oversight from our
>> mentors like Justin and Ian and myself.
>
> Well, that's sufficient, Chris. There should be no "nice to have" aspect.
> The only requirement is that the PMC has the ability to oversee. If we can
> streamline that process, great.
Yeah, I guess to me the PPMC* mentors should be fine to oversee without
double checking with the IPMC*. The podling mentors represent the IPMC* in
my mind and should be its shepherds, not those other IPMC* folks who aren't
participating in the day to day of the podling.
>
>> I'm not sure that teaching the podlings that once they do a committer VOTE
>> with the PPMC that they then have to do an IPMC vote after that is really
>> teaching them the Apache way b/c this isn't the way it'll work when they
>> graduate.
>
>> I think so long as there are active mentors shepherding the experienced
> PMC
>> role on the project, then VOTEs at the PPMC level should be all that's
>> required.
>
> The problem is that the PPMC has no standing. I keep telling people to stop
> using the term IPMC. It is the Incubator PMC. The terms IPMC and PPMC make
> them look somehow equivalent.
I guess that's what I take exception to, I think the PPMC* _should_ have
standing. I saw your other reply to Joe on this and the fact that you're
going to ask for clarification from the Board on seemingly a related
subject. Sounds good to me.
>
> Now, because you have 3+ PMC members in the project, those votes have
> standing, and suffice so long as the rest of the PMC is aware of and has the
> opportunity to exercise oversight.
Yeah, like I said, to me, podling mentors = IPMC* oversight, so if 3+
mentors approve, then that should be it IMHO.
Cheers,
Chris
* I'm still using PPMC and IPMC b/c that's what the docs call them [1].
[1] http://incubator.apache.org/guides/ppmc.html
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: an experiment
Posted by "Noel J. Bergman" <no...@devtech.com>.
Chris A Mattmann wrote:
> From my point of view, it would be nice for podlings with active mentors
> to be able to guide their own decisions, especially if there are 3 active
> mentors and they approve. For example in our case in OODT, we can achieve
> consensus and obtain much of the necessary VOTEs and oversight from our
> mentors like Justin and Ian and myself.
Well, that's sufficient, Chris. There should be no "nice to have" aspect.
The only requirement is that the PMC has the ability to oversee. If we can
streamline that process, great.
> I'm not sure that teaching the podlings that once they do a committer VOTE
> with the PPMC that they then have to do an IPMC vote after that is really
> teaching them the Apache way b/c this isn't the way it'll work when they
> graduate.
> I think so long as there are active mentors shepherding the experienced
PMC
> role on the project, then VOTEs at the PPMC level should be all that's
> required.
The problem is that the PPMC has no standing. I keep telling people to stop
using the term IPMC. It is the Incubator PMC. The terms IPMC and PPMC make
them look somehow equivalent.
Now, because you have 3+ PMC members in the project, those votes have
standing, and suffice so long as the rest of the PMC is aware of and has the
opportunity to exercise oversight. The PMC need not vote unless someone has
a good reason to cast a -1. Again, I'm all for streamlining, as long as it
supports oversight.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Guys,
>From my point of view, it would be nice for podlings with active mentors to be able to guide their own decisions, especially if there are 3 active mentors and they approve. For example in our case in OODT, we can achieve consensus and obtain much of the necessary VOTEs and oversight from our mentors like Justin and Ian and myself.
Also, I'm not sure that teaching the podlings that once they do a committer VOTE with the PPMC that they then have to do an IPMC vote after that is really teaching them the Apache way b/c this isn't the way it'll work when they graduate. I think so long as there are active mentors shepherding the experienced PMC role on the project, then VOTEs at the PPMC level should be all that's required. If IPMC = collection of all PPMC members (after pruning those that aren't active, etc.), that would be fine with me.
My 2 cents,
Chris
On 8/16/10 9:45 AM, "Justin Erenkrantz" <ju...@erenkrantz.com> wrote:
On Mon, Aug 16, 2010 at 9:36 AM, Noel J. Bergman <no...@devtech.com> wrote:
> And if the Mentors aren't being active, voting, etc., then *that* is what
> needs to be addressed.
As I've repeatedly stated before (here and elsewhere), in the podlings
I've been recently involved with, having three mentors isn't the
issue. It's the PMC members who aren't involved sticking their nose
in and trying to poison the community.
> We have one of the largest PMCs in the ASF. If we
I view this as potentially the crux of the problem - people who aren't
stakeholders in the community shouldn't have a say. Right now, they
feel they do. So, if we want to mandate at least 3 mentors - fine,
but that must come at the cost of telling the rest of the IPMC to go
away - unless they actively contribute to the community and earn
merit...of course. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: an experiment
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Mon, Aug 16, 2010 at 9:36 AM, Noel J. Bergman <no...@devtech.com> wrote:
> And if the Mentors aren't being active, voting, etc., then *that* is what
> needs to be addressed.
As I've repeatedly stated before (here and elsewhere), in the podlings
I've been recently involved with, having three mentors isn't the
issue. It's the PMC members who aren't involved sticking their nose
in and trying to poison the community.
> We have one of the largest PMCs in the ASF. If we
I view this as potentially the crux of the problem - people who aren't
stakeholders in the community shouldn't have a say. Right now, they
feel they do. So, if we want to mandate at least 3 mentors - fine,
but that must come at the cost of telling the rest of the IPMC to go
away - unless they actively contribute to the community and earn
merit...of course. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Leif Hedstrom <zw...@apache.org>.
On 08/16/2010 10:36 AM, Noel J. Bergman wrote:
>> Again, if the PPMC has 3 or more PMC members, it should be capable of
>> mustering the necessary votes by virtue of those PMC members voting.
>> Have I repeated the "every Incubator project should have at least 3 PMC
>> members providing oversight" mantra enough, yet?
> And if the Mentors aren't being active, voting, etc., then *that* is what
> needs to be addressed. We have one of the largest PMCs in the ASF. If we
> can't get enough active PMC Members, then that fact alone limits the size of
> the Incubator.
+1 .
Lack of binding votes was seen as the main "problem" for Traffic Server
during incubation, other than that, I think the process mostly "just
works" as it is.
Cheers,
-- Leif
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: an experiment
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Again, if the PPMC has 3 or more PMC members, it should be capable of
> mustering the necessary votes by virtue of those PMC members voting.
> Have I repeated the "every Incubator project should have at least 3 PMC
> members providing oversight" mantra enough, yet?
And if the Mentors aren't being active, voting, etc., then *that* is what
needs to be addressed. We have one of the largest PMCs in the ASF. If we
can't get enough active PMC Members, then that fact alone limits the size of
the Incubator.
We've also got a nice growth rate, as I'll attest to after I put in the next
round of PMC membership approvals (next thing after today's board report).
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: an experiment
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I'd like to start experimenting with different organizational
> and procedural approaches to the projects I participate in
> here. What I want to do is to see how far I can push
> the envelope on the whole notion of empowerment and
> self-governance in an incubating project, following the
> lessons I've learned from httpd's treatment of the subprojects
> it happens to be responsible for.
The reason for the existence of the PPMC is to help foster that
self-governance, but we must recognize two things. One, the projects are
not yet entitled to full self-governance. That's why they are in the
Incubator. Two, the ASF Bylaws name *the* governing body for each project
as the PMC, which is required to provide oversight.
> The first idea should be fairly straightforward: that for
> the projects I participate in (so far thrift and sis), that
> the IPMC delegates to the PPMC the decision-making process
> for voting in new committers
-1
The PPMC has no legal or structural standing with the ASF. Decisions are
made -- and required to be made -- by each project's PMC, as per the Bylaws.
If the PPMC has 3 or more PMC members, it should be capable of mustering the
necessary votes by virtue of those PMC members voting.
Now, if the ASF Board would like to approve a different behavior, I'd accept
that, but I don't believe that a PMC should take it on itself to skirt ASF
Bylaws, and we've tried very hard to structure the Incubator within them.
> The second idea is more controversial: to hold IPMC votes to
> admit all significant committers to those projects to the IPMC
> itself. The purpose of this concept is to allow those who
> best know the codebase to provide IPMC oversight over it,
> especially as it pertains to releases.
-1
The Incubator PMC, unlike other PMCs, isn't preoccupied with the codebase;
it is about community. And even with respect to code, we have far too much
experience with projects attempt to put out improper releases to abandon our
oversight obligations.
Again, if the PPMC has 3 or more PMC members, it should be capable of
mustering the necessary votes by virtue of those PMC members voting.
Have I repeated the "every Incubator project should have at least 3 PMC
members providing oversight" mantra enough, yet?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by Mark Struberg <st...@yahoo.de>.
Given that the IPMC can still veto a decision of the podling, I like this idea.
+1
LieGrue,
strub
----- Original Message ----
> From: "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>
> To: "general@incubator.apache.org" <ge...@incubator.apache.org>
> Sent: Wed, August 11, 2010 7:49:45 PM
> Subject: Re: an experiment
>
> Hi Joe,
>
> > The first idea should be fairly straightforward: that for
> > the projects I participate in (so far thrift and sis), that
> > the IPMC delegates to the PPMC the decision-making process
> > for voting in new committers: basically rolling back the clock
> > to May 1, 2007 on guides/ppmc.html.
>
> +1 from me, and I'd like to OODT to that experimental list as well :) It
> would probably make sense for Lucy too, but we're in our nascence there (not
> that it should matter).
>
> >
> > The second idea is more controversial: to hold IPMC votes to
> > admit all significant committers to those projects to the IPMC
> > itself. The purpose of this concept is to allow those who
> > best know the codebase to provide IPMC oversight over it,
> > especially as it pertains to releases.
>
> I wouldn't have a problem with this.
>
> Cheers,
> Chris
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: Chris.Mattmann@jpl.nasa.gov
> WWW: http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: an experiment
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Joe,
> The first idea should be fairly straightforward: that for
> the projects I participate in (so far thrift and sis), that
> the IPMC delegates to the PPMC the decision-making process
> for voting in new committers: basically rolling back the clock
> to May 1, 2007 on guides/ppmc.html.
+1 from me, and I'd like to OODT to that experimental list as well :) It
would probably make sense for Lucy too, but we're in our nascence there (not
that it should matter).
>
> The second idea is more controversial: to hold IPMC votes to
> admit all significant committers to those projects to the IPMC
> itself. The purpose of this concept is to allow those who
> best know the codebase to provide IPMC oversight over it,
> especially as it pertains to releases.
I wouldn't have a problem with this.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org