incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <>
Subject Re: Is the incubator full?
Date Fri, 26 Aug 2016 00:58:05 GMT
I like the slider metaphor.

When I mentor, I like to start with the slider hard over by active,
especially during champion phase, but moving toward passive after the first
clean release and report or two.

I don't think that inactive projects actually require all that much thought
or action. The ones that take time are the ones with a poisonous
personality or total melt-down due to misunderstanding what Apache is. For
instance, Datafu hardly takes any effort for it to sit in incubator.
Corinthia took a very lot of time over a short time to resolve.

As I see it, we have a variety of kinds of workloads that have variable
levels of scalability. The mentorship is supposed to scale by picking off
volunteers from incubation projects as they come by ... Taylor is a poster
child recently for that.

Release checking is a less scalable resource that we have not scaled lately.

Explosion cleanup is also much less scalable, partly because it is hard to
predict what the workload will be and partly because it is unpleasant work.

If we decide that we want to meter the number of projects and can agree on
a metering level, it is actually not that hard to do the throttling on
intake. All we have to do is change our voting to be a periodic stack
ranking of incoming candidates to fit into available holes.

Agreeing on the number of available holes is a lot harder to do. Getting
consensus on that probably means that we need to identify some functions
and let those volunteering for that function decide that the current load
is higher than, lower than or equal to what they can handle. If all of our
functions agree that we can handle more, we increase slots. If one function
feels that they are overloaded, we decrease slots. Else, slots remains the

My guess is that doing this well will feel a lot like busywork /

Does anybody else have a thought on that?

On Thu, Aug 25, 2016 at 5:40 PM, P. Taylor Goetz <> wrote:

> > On Aug 24, 2016, at 5:41 PM, Roman Shaposhnik <>
> wrote:
> >
> >> On Tue, Aug 23, 2016 at 7:26 AM, John D. Ament <>
> wrote:
> >> All,
> >>
> >> I'm wondering if the Apache Incubator is full right now?
> >
> > It seems that this question gets asked about once a year. The consensus
> > always seems to be that this may not be the right question to ask. It is
> > sort of like asking whether Hadoop has too many lines of Java. On a more
> > serious note, I think that the takeaway from each of these threads over
> > the years has been that the right question to ask is whether we're
> providing
> > podlings with support they need to emerge as TLPs ASAP. I think that
> should
> > be the focus of IPMC. A maniacal focus on getting the projects out
> either as
> > TLPs or to the Attic should, indeed, be a constant priority for us. I
> know I'm
> > in the minority when I say this, but I think this should be one of the
> few areas
> > where IPMC and/or IPMC Chair gets to drive the inquiry as opposed to
> mentors
> > doing it. Wave sitting in the Incubator since 2010 is clearly NOT in
> anybody's
> > best interest.
> In my limited experience with mentoring, there seems to be a spectrum of
> mentoring "styles" (for lack of a better word):
> 1. Active
> Mentors actively push/nudge/prod the podling toward what it takes to
> graduate. They ask questions like "Is it time for a release?", "What is the
> plan for expanding the community?",  etc. in effect, the podling is pushed
> toward the finish line (graduation). The benefit to the IPMC is that
> podlings, theoretically graduate sooner, and graduate with an understanding
> of the *current* ASF policies/guidelines.
> 2. Passive
> Mentors are mostly hands-off and reactive vs. proactive. Email threads
> with "[MENTOR]" in the subject will trigger a response/review, as will VOTE
> threads, signs of community strife, etc. The benefit to this approach is
> that it forces podlings to learn to navigate ASF policy on their own (which
> can be daunting to newbies, but a skill that all TLPs should have).
> In reality Active/Passive is a slider that moves depending on the nature
> of the podling community all the way down to the nature of a particular
> interaction. I bounce back and forth with my approach depending on the
> context.
> My point is about answering "How to graduate podlings faster?" Which I
> feel Roman is alluding to. If we're push podlings to graduate, we may want
> to consider more concrete/documented criteria for greaduation.
> -Taylor
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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