On Sat, 10 Aug 2019 at 12:45, Paul King <pa...@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 <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 > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
