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? On Fri, Aug 9, 2019 at 3:04 PM Justin Mclean <jus...@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-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
