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 <w...@apache.org> Sent: Tuesday, August 13, 2019 9:22:26 AM To: general <general@incubator.apache.org> 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 <gst...@gmail.com> 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. Regards, Dave > On Aug 13, 2019, at 9:09 AM, Ted Dunning <ted.dunn...@gmail.com> 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 <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://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread.html%2F495ed84b43c1ba2662075a6c8c869bcd337b6bf4bc1895149c1483de%40%253Cgeneral.incubator.apache.org%253E&data=02%7C01%7C%7Caab64e7826a14f92ed3508d7200a71b9%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637013101534070713&sdata=zrEMkadVkFV5QIJ1uKenqFGaWvpae%2F6ofq3T%2FOXjWS4%3D&reserved=0 >> >>> >>> 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: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
