incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Mclean <jus...@classsoftware.com>
Subject [DISCUSS] IPMC votes on releases
Date Fri, 09 Aug 2019 05:04:14 GMT
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


Mime
View raw message