> On Aug 12, 2019, at 1:34 PM, Ted Dunning <ted.dunn...@gmail.com> wrote: > > On Mon, Aug 12, 2019 at 11:10 AM Dave Fisher <w...@apache.org > <mailto:w...@apache.org>> wrote: > >> >> >>> On Aug 12, 2019, at 10:02 AM, Ted Dunning <ted.dunn...@gmail.com> wrote: >>> >>> On Mon, Aug 12, 2019 at 9:24 AM Jim Jagielski <j...@jagunet.com> wrote: >>> >>>> >>>> >>>>> On Aug 12, 2019, at 10:44 AM, Ted Dunning <ted.dunn...@gmail.com> >> 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. 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. >>>> >>>> Then the ones that don't have enough mentors still require the 3 +1 >>>> 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, then >>>> 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 a >>> 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] https://lists.apache.org/thread.html/495ed84b43c1ba2662075a6c8c869bcd337b6bf4bc1895149c1483de@%3Cgeneral.incubator.apache.org%3E > > 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).
