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 Tue, 13 Aug 2019 16:22:26 GMT
Hi Ted,

This subthread as named by Greg is really about this:

> On Aug 11, 2019, at 5:56 PM, Greg Stein <> wrote:
> See further below for an unfortunately trimmed thread. A couple paragraphs
> that I wrote early-thread are important to add:
> ----
> Option (F): stop calling them official ASF releases, which means PMC votes
> are not required.
> ——

I am for option (F) with the addition of Myrle’s [REVIEW] until such time as the podling
is fully compliant with Apache Release Policy and goes through the usual process. Abiding
by the Apache Release Policy would remain a Graduation Requirement.

So, we treat these releases as not fully approved the same way we treat Binary Conveniences.

I think that this pattern grows the PPMC into a true PMC better by expecting that licensing
issues which require vigilance become part of the Project’s DNA in a more organic way.


> On Aug 13, 2019, at 9:09 AM, Ted Dunning <> wrote:
> Dave,
> I understand the problem with long delays. What I don't understand is how
> the proposal changes any of that.
> 90% of project release still require additional votes. How will that change?
> Every other change is peripheral.
> On Tue, Aug 13, 2019 at 8:37 AM Dave Fisher <> wrote:
>>> On Aug 12, 2019, at 1:34 PM, Ted Dunning <> wrote:
>>> On Mon, Aug 12, 2019 at 11:10 AM Dave Fisher < <mailto:
>>>> wrote:
>>>>> On Aug 12, 2019, at 10:02 AM, Ted Dunning <>
>> wrote:
>>>>> On Mon, Aug 12, 2019 at 9:24 AM Jim Jagielski <>
>>>>>>> On Aug 12, 2019, at 10:44 AM, Ted Dunning <>
>>>> wrote:
>>>>>> ...
>>>>>>>> "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.
>> 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
>>>>>>> releases don't have enough mentor votes to follow this path.
>>>>>>> The 10% that do have enough votes can easily follow this process.
>>>>>> Then the ones that don't have enough mentors still require the 3
>>>>>> binding votes. The idea is that if the podling already has it, then
>> the
>>>>>> IPMC "vote" is more procedural than anything else. If they don't,
>>>>>> either the mentors need to step up or the IPMC fills in the gap.
>>>>>> The goal is to avoid having the Incubator be a gate-keeper.
>>>>> I don't understand how this is all that different from what we have
>> now.
>>>> If
>>>>> three mentors (and thus IPMC members) vote yes, then opening up the
>> vote
>>>> to
>>>>> include the IPMC is just like what you said, "we have three votes
>> already
>>>>> and unless somebody points out something heinous, this is going to be
>>>>> release". Whether the IPMC is a gatekeeper or a rubber stamp in these
>>>> cases
>>>>> is a tiny matter of nomenclature because the effect is typically a
>> rubber
>>>>> stamp (although some of these releases are examined carefully and
>> things
>>>>> turn up).
>>>>> In the large majority of cases, the Incubator is definitely not a
>>>>> gatekeeper. If anything, the non-mentor IPMC votes are enablers that
>>>> allow
>>>>> a release to go forward when it would otherwise fail.
>>>> A week or two (an uncertain time) to do release votes as opposed to what
>>>> may already be a significant increase to a minimum 3 days will FEEL
>> like a
>>>> closed GATE. (For example Zipkin really felt gated.)
>>> Dave,
>>> I don't understand your point.
>> My point is that what you describe below are the ideal results. We all
>> know that while the podling itself can do release votes in 72 hours it
>> often takes the IPMC much more than 72 hours to vote. It used to be weeks
>> and has improved significantly to where most podlings can be done inside of
>> one week.
>> The timing and uncertainty of this is too much for some previously
>> established communities. For instance I think that this indeterminate lag
>> is one of the causes that made Zipkin a poor fit here.
>> We've relaxed DISCLAIMERs. Should we wait to see if this improves the
>> situation, or should we do another small step and essentially follow
>> Myrle’s Review plan[1] for all general@ votes?
>> Regards,
>> Dave
>> [1]
>>> Currently, a podling does a vote. If they (it does happen, but rarely)
>> get
>>> 3 mentor votes, then they can immediately call for comments / votes on
>> the
>>> IPMC list. If nothing bad turns up, they are done.
>>> If something really bad gets found at that point, it isn't the fault of
>> the
>>> process. It is the nature of release votes with different people looking
>> at
>>> different things. Further, a release wouldn't necessarily be blocked at
>>> that point, but if the problem really is bad, then it is good practice
>> for
>>> all +1 votes to switch to -1 so the vote fails and a new candidate can be
>>> rolled.
>>> The proposal Jim made said that there would be 72 additional hours to
>>> review after the vote passes the podling vote. It may be that there is a
>>> suggestion that this additional 72 hours could start immediately upon
>>> getting three mentor votes but this is very much a corner case since it
>>> would be a fraction of the 10% of the time that three mentors actually do
>>> vote. If the three mentors take a day or two to vote, then the only
>>> difference in the 10% case is a day or so acceleration.
>>> This just doesn't sound like it helps all that much. It changes 3 days +
>> 3
>>> days into 3 days + 3 days 90% of the time and has some potential to
>> change
>>> it into 3 days + 1-2 days less than 10% of the time.
>>> That is my point. Either I completely misunderstand what is being
>> proposed
>>> or it doesn't really make a significant difference. If I misunderstood, I
>>> would love to hear how and it seems like it would good to improve the
>>> description of the change. If it doesn't matter, we can make the change
>> or
>>> not and there shouldn't be much argument either way (because it doesn't
>>> matter).

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

View raw message