incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
Date Tue, 13 Aug 2019 16:09:10 GMT
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 <wave@apache.org> wrote:

>
>
> > On Aug 12, 2019, at 1:34 PM, Ted Dunning <ted.dunning@gmail.com> wrote:
> >
> > On Mon, Aug 12, 2019 at 11:10 AM Dave Fisher <wave@apache.org <mailto:
> wave@apache.org>> wrote:
> >
> >>
> >>
> >>> On Aug 12, 2019, at 10:02 AM, Ted Dunning <ted.dunning@gmail.com>
> wrote:
> >>>
> >>> On Mon, Aug 12, 2019 at 9:24 AM Jim Jagielski <jim@jagunet.com> wrote:
> >>>
> >>>>
> >>>>
> >>>>> On Aug 12, 2019, at 10:44 AM, Ted Dunning <ted.dunning@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).
>
>

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