incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Gruno <>
Subject Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
Date Mon, 03 Aug 2015 09:21:13 GMT

On 2015-08-03 09:37, Bertrand Delacretaz wrote:
> On Mon, Aug 3, 2015 at 4:05 AM, Roman Shaposhnik <> wrote:
>> ...who else thinks the movement towards empowering
>> PPMCs and making IPMC very much like the board makes sense?...
> How is that different from the status quo where a podling with active
> mentors can have their releases +1ed by their mentors, requiring
> minimal interaction with the IPMC?
As you say, releases can - if done right - be done with minimal friction 
from the IPMC, so the issue seems more to be an issue of perception and 
procedure than an issue of policy. There is a clear distinction between 
how the board acts towards TLPs and how the IPMC acts towards podlings, 
and in my opinion there should be: TLPs are _expected to know how to 
act, how to release, how to self-govern_. They have learned this through 
trial and error, many of them in the Incubator, and have built up 
procedures and cultures that enable them to (mostly) govern themselves. 
Podlings are _in training to be like that_, and even with 4, 5, 6 
mentors, it has been shown time and time again (as I believe Marvin also 
mentioned), that there will be issues with the first one or two 
releases, as is only natural when a project is learning how to do 
Apache-style releases, and then the IPMC says "hang on, you need to do 
these things differently, fix this, that, and then do this", and then 
the podling slowly adapts to the way we do releases. As we continue to 
let in more and more podlings, it is also safe to assume, that the 
number of 'initial release bugs' will increase, thus this system becomes 
even more important.

To sum up my view: We have a release process that has shown many times 
that it both works and is necessary for podlings, especially on the 
first release. I think this is awesome, and I don't see the need to 
change this specific policy - *but perhaps we could ease the process, as 
I suggested last week, through better tooling and education.*

Allow me to also ask this question: If there is a _visible_ need for 
this existing policy, as has been shown on numerous occasions, how is 
empowering PPMCs by removing the policy going to solve or help the 
issue? I am all for a hands-off approach if it leads to a desired goal 
(wholly or partially), but this specific proposition seems to be 
counter-intuitive to me.

Therefore, I will suggest the same thing I did last week:

- Keep the existing policy
- Make better processes and tooling to aid podlings in their first 
release(s) (see my previous email for details)
- Consider a mentor rotation/swap-in principle to ensure a fresh 
unbiased/non-myopic governance.

Heck, I'd even, to some degree, recommend these steps for TLPs, but eh, 
that's another story :)
If we can create procedures and tools that can do most of the basic 
legal and structural checks in new release candidates, we could cut down 
the time spent arguing about the nitty gritty details, and a lot of the 
unfortunate situations where a podling needs to release fast, but gets 
caught in a legal issue, could be avoided or at the very least be 
resolved a lot faster.

With regards,

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

View raw message