incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [DISCUSS] IPMC votes on releases
Date Sat, 10 Aug 2019 11:55:20 GMT
On Sat, 10 Aug 2019 at 12:45, Paul King <paulk@asert.com.au> wrote:
>
> Another variation/option for those using the WIP disclaimer might be that
> since the WIP disclaimer kind of says this release doesn't have "full
> official" status from an ASF point of view then one way of thinking about
> it is that perhaps full official IPMC endorsement is less of a requirement
> so IPMC voting could be 3 days but lazy. If you don't get more -1 votes
> than +1 votes after 3 days, you can go ahead and publish. Outside WIP
> disclaimer projects, if there are projects which are repeatedly not getting
> enough IPMC votes, then IPMC membership by an experienced PPMC member could
> be considered as an option, so +1 for your (D) I believe.
>
> I have no problem giving +1 to (E) at all but in reality, it is almost no
> effort for the 3 mentioned IPMC members on the dev list to just +1 the IPMC
> vote, so are we picking up the real problem podlings?

If the IPMC members have +1ed the vote on the dev list, won't these
votes count if the vote is continued on the general@ list?
Do they really have to re-affirm their votes?

I agree that the issue seems to be more about podlings with
insufficient/inactive IPMC reviewers.

> On Fri, Aug 9, 2019 at 3:04 PM Justin Mclean <justin@classsoftware.com>
> wrote:
>
> > Hi,
> >
> > One of the incubator pain points is the double voting on releases first by
> > the podling and then by the IPMC.
> >
> > Historically there been a lot of discussion about this and a couple of
> > proposals to try and change it, but none have been accepted. There have
> > been proposals on alternative ways to vote and to ask for guidances which
> > have been accepted, but podlings don’t seem to take these options up. I’m
> > hoping the recent DISCLAIMER-WIP is one that is used more by podlings, and
> > go some way to helping podling get releases out, but time will tell.
> >
> > When consider what to do about this, please keep this in mind:
> > 1. Only PMC members can have binding votes on releases (it’s in our
> > bylaws) so a minimum of 3 IPMC votes are require to make a release.
> > 2. Podlings are not TLP and don’t have a PMC and PPMC members votes are
> > not binding on releases.
> > 3. The IPMC picks up some serious issues in (about 1 in 5) releases by
> > checking this way. This is mostly, but not always, on the early releases.
> >
> > So option (A) would be to get the Bylaws changed and treat podlings as
> > TLPs.
> >
> > Another option (B) is to get all mentors to vote on every release. We’ve
> > tried this via various means and it seems only a couple of podlings can
> > manage this.
> >
> > One (perhaps not carefully considered) option (C) would be to vote in all
> > PPMC members as IPMC and make PPMC members IPMC members when projects are
> > first created rather than incubator committers. If we did this we could
> > optionally gate graduation on a review of a podlings releases but that may
> > be unpopular. There have also been complaints in the past that he IPMC is
> > too large, so increasing the IPMC size this way may also not be popular.
> >
> > A variation on (C) let call it option (D) would be to vote in podling
> > release mangers into the IPMC after they have done a number of releases
> > along with podling committers that provide good feedback on a number of
> > release candidates. That way when starting out a podling is likely to need
> > the IPMC help, but one they have a few releases under their belts they will
> > have enough IPMC votes without having to reply on mentors or other IPMC
> > members. It would also encourage more careful voting on releases, If you
> > just go +1 with giving some detail you’re not going to be voted into the
> > IPMC. This wouldn't require any bylaws or policy change, we could just go
> > ahead and do it. It would require the mentors help in identifying good
> > candidates.
> >
> > One further idea I have is (E) is that if a podling does have 3 IPMC votes
> > on it dev list and are using the DISCLAIMER-WIP disclaimer, they can just
> > notify the IPMC that they are making a release, the IPMC can review it and
> > and any issues or feedback found can incorporated into the next release or
> > before graduation as per [1]. This may mean that there’s a risk that a
> > release has to be taken down and redone - (see issues that are blockers in
> > that ticket), but most issues found over the notification it would be
> > business as usual.
> >
> > So IMO options (A) and (C) above seem unlikely to happen, and (B) isn’t
> > really working, but option (D) combined with (E) along with the recent
> > DISCLAIMER-WIP I think could would improve the situation.
> >
> > Does anyone have any other ideas they care to share?
> >
> > Thanks,
> > Justin
> >
> > 1. https://issues.apache.org/jira/projects/LEGAL/issues/LEGAL-469
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message