incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: [DISCUSS] IPMC votes on releases
Date Sat, 10 Aug 2019 14:41:07 GMT
Option (F): stop calling them official ASF releases, which means PMC votes
are not required.

On Fri, Aug 9, 2019 at 12:04 AM Justin Mclean <>

> 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.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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