incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
Date Tue, 13 Aug 2019 18:45:17 GMT
When I used to do endless apache way talks I used to say "if you are using an Incubator project
expect to invest in both engineering and legal, but once a project is a TLP your legal can
reduce and engineering becomes about your use rather than community progrwe towards TLP"

In other words Jim is right IMHO


Sent from my phone, you know what that means - sorry

From: Dave Fisher <>
Sent: Tuesday, August 13, 2019 9:22:26 AM
To: general <>
Subject: Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

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:

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