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 <w...@apache.org> wrote: > > > > 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). > >
