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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
