On Mon, Aug 12, 2019 at 11:10 AM Dave Fisher <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. 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).
