Greg Stein wrote:
> Noel J. Bergman wrote:
>> Greg Stein wrote:
>>> Make the podling a TLP comprised of *only* ASF Members, with at least
>>> *three* minimum (preferably more, to deal with idle times).
>> How does that differ from the current system (given the assumption of 3+
PMC
>> Members), except that it precludes potential oversight from others -- the
>> flipside of "solves the peanut gallery problem" that apparently plagued
>> Subversion?
> Presumably 3+ ASF Members is sufficient oversight. Given these Members
> are the ONLY PMC members, then they must also remain pretty active in
> their podling which implies oversight.
Well, that has been an issue with many podlings so far. Subversion is an
exception, not the rule, although I don't know that we've got a handle on
the ratio of projects for which getting 3 binding votes isn't an issue.
> My proposal ups that from "3+ PMC members" to "3+ ASF
> Members", which (IMO) is a stronger guarantee.
Greg, *the* most common problem has been IP and release related. RAT has
fixed a lot of it, but ASF Members were not even remotely immune to the
problem. Without RAT, I suspect we'd still be mired in the muck, and
needing as many eyes as we've had.
> And do not minimize the peanut gallery problem. That is a very real
> issue
I'd really like to know how widespread it is, other than that it bit a burr
under the saddle of some ASF Members on a few projects. And I'm still not
minimizing its impact on even a single project, just wondering about
prevalence.
> Empirically speaking... no, you cannot. The peanut gallery gets in the
way.
Let's agree to resolve the peanut gallery issue, and move on to see if there
are any other issues.
> > We could do that now, except that people have previously disliked the
idea
> > of $podling.apache.org being provided prior to graduation, for either
e-mail
> > or web site addresses. If the consensus is to change that, fine.
> I'm not asking for consensus. I'm proposing a whole new approach.
Yes, but we still need to find out of the Board will agree to providing
$X.apache.org resources, and branding, for provisional projects.
> Yes. Thus, my point that the Board is going to have to weigh in on
> this topic at some point. But it needs some rounds of support and
> beat-downs here on general@ before it is in a reasonable proposal
> state for the Board. We also need some podlings who would like to
> volunteer for this new approach, for the Board to consider.
Well, if it isn't clear, I'm not trying to tear this down on you, and if
OODT wants to give it a go, I'd support the experiment. But don't we first
need to address ...
> > what *are* the graduation metrics, and who votes on
> > graduation?
> I suspect that the metrics would be defined by the Incubator:
> basically the checklist of considerations already present.
> There could be two ways to graduate:
> 1) the PMC self-graduates
> 2) the PMC proposes graduation to the Board
> I prefer the latter, as a final checkup/signoff to the process. The
> PMC would need to arrive with $materials demonstrating satisfactory
> completion of all incubation requirements.
Is there any role for the Incubator, or is it strictly between the podling
and the Board for this class of podling?
>>> Restrictions like those on websites or releases could be relaxed. It
>>> was a fair question to ask, "why keep those in place? what are we
>>> trying to protect?"
>> Why relax them uniquely for such projects? And presumably we are
protecting
>> the ASF brand, as well as downstream consumers who rely on our output,
>> including clean licensing, etc. But getting back to the first point, is
>> there some rationale to relax them for these podlings and not for others?
>> If we can justify them for some, should we re-examine them in general?
> Yup, good questions all. It was a fair point raised on IRC that I'm
> bringing here.
Fair enough. :-)
>>> Using this model decentralizes the process
>> So does having 3+ PMC Members today.
> The IPMC is anything but decentralized. And empirical evidence shows
> it to peanut-gallery-ism.
Empirical evidence also shows that we rarely hear from most projects except
when they need binding votes or put in a report. Again, I agree with your
idea of polling the community.
>> Remember that the Board created the Incubator because of problems with
existing
>> projects trying incubation on their own. But we have learned a lot since
>> then.
> Yups. The Incubator has provided a lot of focus on what we need, what
> kinds of problems arise, and what we don't need.
> I maintain that "additional oversight" is not required given the
> composition of these TLPs membership (all ASF Members).
I may agree with you now, given RAT. As I've noted before, ASF Members have
not been immune to release issues. And hopefully we won't come back to
realize that not all ASF Members aren't good at project building. Not every
ASF Member is you, Justin, Roy, Bertrand, Jukka, etc. I'm not even sure
that most are.
> Reference Justin's point about the Subversion PMC not recognizing
> their own self-governance. Their initial introduction to the ASF put
> them at the mercy of an invisible and nebulous group called "the
> Incubator Project Management Committee". If the initial intro was a
> self-governing PMC, then I think we wouldn't have the same kinds of
> (admittedly minor) problems with queries about how to get certain
> things done, or if they were allowed.
I'd be cautious about risk / reward ratio related to making structural
changes in response to "minor problems." That said, I'm interested in your
experiment. We won't know until we try.
> I suspect the OODT guys might want to try this (it has four ASF
> Members as Mentors who could comprise the PMC).
How long do you think it will take to work this out? Can we have something
for the Board by the September meeting?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
