incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <>
Subject Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
Date Mon, 12 Aug 2019 17:34:05 GMT
Hi -

> On Aug 12, 2019, at 8:44 AM, Julian Feinauer <> wrote:
> Hi Ted,
> dont get me wrong, I'm rather new to the ASF, the incubator and especially the IPMC.
So my perspective might be different. But, I understand the frustration that some may have
and I leant that there have been many trials to change things which didn’t go the way we
> The "fear" or concerns I have is that loosening some requirements feels a bit like resigning
which would be a horrible thing as the incubator is one of the (if not the) most important
projects in the ASF.
> And I don’t object that much with having different classes of releases (its not elegant
but acceptable IMHO) but the thing I'm really concerned about is the lack of possibilities
to learn for podlings.
> If we come at the end to the modus operandi of "Yeah, simply release as is but use this
disclaimer or that NOTICE and later in the project we will do it 'right'" that would be pretty
> But perhaps I'm too spoiled as I had the luck to be in several podlings with Justin and
Chris Dutz who both took lots of time and did an excellent job in helping me and all other
freshmen to really learn what this Apache Release policy is about and how to do it right.
> And this is something so important that I want every other podling / newcomers to the
ASF to experience.
> I know that this might sound provocative and perhaps some people might disagree but perhaps,
if we know that we have not enough "mentor-power" we should be more careful about picking
up new projects in the incubator if we are not sure how to bring them to TLP successful?

We definitely do need to be more careful. I think that we need to empower and better define
the Champion role so that two things are done:

(1) The Champion makes sure that the incoming project is truly on board. This means testing
the incoming community both donor and the initial committer list that they understand how
Apache Way governance works. This is more than release policy, it is about using the dev@
list to make asynchronous decisions within the podling community. I think that this does not
happen enough and mentors lose track of podlings because they can’t see what is happening
without being entwined in GitHub issues and commit emails.

(2) The Champion makes sure that there are enough Mentors who have taken a podling through
the Incubator. A good mix of “Junior” Mentors like I was once and Julian is now is good,
but having old veterans like Jim, Jean-Baptiste, Julian, Justin, and Bertrand among others
is truly critical.

See [1] for a good graph showing the ebb and flow of Incubator podlings through time.



> Julian
> Am 12.08.19, 17:34 schrieb "Ted Dunning" <>:
>    Julian,
>    I love the sentiment, but increasing the probability of mentor-only
>    approval by 10x is going to take a lot of something that we haven't had the
>    last five times we have tried to do this. The current system is a bit
>    frustrating, but having what amounts to mentors-at-large like Justin and a
>    few others is the only way we have right now to solve the problem of
>    inspecting releases (and helping to improve them).
>    And regarding two level of artifacts, we already have two kinds of podling
>    release artifacts. Those are releasable and defective (and thus not
>    releasable). That can't change since it is inherent in the release ground
>    rules and the fact that incoming podlings don't know the ground rules. The
>    only change is to make the defective artifacts provisionally releasable.
>    On Mon, Aug 12, 2019 at 7:56 AM Julian Feinauer <
>> wrote:
>> Hi Ted,
>> but instead of questioning the Bylaws or introducing two classes of
>> artifacts I would rather try to improve mentor votes as this is something
>> we can do incubator internal.
>> And its always better to cure the cause then the symptoms : )
>> Julian
>> Am 12.08.19, 16:44 schrieb "Ted Dunning" <>:
>>    On Mon, Aug 12, 2019 at 5:20 AM Jim Jagielski <> wrote:
>>> ...
>>> This does NOT mean that the IPMC should be gatekeepers though...
>> Just as
>>> PMC chairs are the "eyes and ears of the board", mentors are the
>> "eyes and
>>> ears of the IPMC". The IPMC "vote" should be little more than a
>> formality.
>>> IMO, if mentors are IPMC members, and there are at least 3 binding
>> votes on
>>> the podling list, and the mentors are acting as IPMC members when
>> they
>>> vote, then any other additional vote in the IPMC is not required...
>> in
>>> essence, consider it like extending the vote for a lazy consensus,
>> so to
>>> speak:
>>>   "The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and
>>> pointers here). We have 3 (or more) binding votes from mentors. We
>> are
>>> giving the IPMC and additional 72 hours to vote on said release."
>>    This is good in theory, but as Justin has pointed out, 90% of podling
>>    releases don't have enough mentor votes to follow this path.
>>    The 10% that do have enough votes can easily follow this process.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message