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 Mon, 12 Aug 2019 17:02:47 GMT
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.

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