incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
Date Sun, 26 Jul 2015 17:08:17 GMT
> On Sun, Jul 26, 2015 at 1:20 AM, Niclas Hedhman <> wrote:

>> About 40% of the last 100 threads on general@ is "vote release"...
>> Cut that away is a good start in reforming the Incubator…

Many of those vote threads are very high quality and valuable.

Successful vote threads are short: a few +1 votes and it's over.  Frequently,
those +1 votes will be accompanied by a description what was reviewed.
Unsuccessful vote threads yield targeted action items and cogent explanations.
Since the end of 2013, when the Incubator community established an improved
consensus about release requirements, fewer RCs get rejected and rancor has
been rare.

On Sun, Jul 26, 2015 at 4:38 AM, Branko Čibej <> wrote:

> It's now a lot better than it was a
> couple years ago, when in some instances it took a month or more ...

Yes, we have for the most part solved the problem of RCs twisting in the wind.
Both proposals in this thread will bring that problem back.

Mentor attrition is a fundamental law of the Incubator: because Mentors are
not core contributors, they fall away at increased rate.  It is not possible
to change that fact, only to compensate for it.

The wider IPMC has a certain limited capacity for picking up the slack on
release votes.  Since the end of 2013, we have been using that precious
capacity wisely.

These proposals squander that capacity and put it all back on the Mentors.
Some of those Mentors will be unavailable when they are needed, compounding
the difficulties faced by smaller and more troubled podlings.

> Concretely: I think it's perfectly OK to review podling releases after
> the fact. The incubation disclaimer tells users clearly enough that they
> should be extra careful when using releases from incubating projects.

We routinely see problematic release candidates on general@incubator.  It
would seem that the expertise and temperament for exacting release QC is not
evenly distributed among the Mentor corps -- just like other valuable skills
and talents.

Since 2013, the wider IPMC in collaboration with Mentors has been working
well at cleaning up problematic releases in an expedited manner -- and once a
podling is producing clean releases regularly, it is probably nearing
graduation and will not be affected by the extra 3 days for long.  I don't see
any urgency to change this dynamic.

> The other frustration is of course evident in the Ignite graduation
> discussion.

The outcome of the Ignite graduation discussion was never in doubt.  The wider
IPMC was never going to vote down graduation when there were multiple
attentive Ignite Mentors united in favor -- it was only a matter of time
before people came around.

I think the discussion was more voluminous than it needed to be, but I
attribute that to individual participants sending too many emails in one day.
1-2 per day on a given thread is a good rate.

In the meantime, interested podling observers got to witness a decent debate
on project independence and off-list dev discussion -- which is generally one
of the hardest aspects of Apache-style open development to master.

> The only downside of this proposal is that it assumes that every podling
> has at least three active (!) mentors. That doesn't always happen; and
> currently we expect the podling to chase down inactive mentors or find
> new ones. If we adopt Jan's proposal, I'd expect the IPMC to take a more
> active role in finding mentors for podlings.

Recruiting Mentors for podlings at any stage other than entry has always been
difficult.  It would be deeply unfair to small podlings to establish a policy
which denies this reality.

Marvin Humphrey

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message