incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Feinauer <j.feina...@pragmaticminds.de>
Subject Re: [DISCUSS] IPMC votes on releases
Date Sat, 10 Aug 2019 12:52:26 GMT
Hi,

thanks Justin for bringing that up.
I have perhaps a different perspective than many others because I was / am mostly active in
several podlings and just very recently became IPMC member (no apache member).

But, assuming that each podling has three active mentors, each podling should have 3 +1 IPMC
vote before the RC goes to general@ and then is, as Sebb says below basically a "lazy" consensus
vote as 3 +1 are present and if no one throws in a -1 it will pass regularly and is a regular
release.

This brings me to the point. The assumption "three active mentors" is pretty strong.
In the podlings I have been active with I observed three categories of Mentors:

- generally present (best!)
- usually not present but active in VOTE threads or report signoff (so-so)
- not active at all

So from my perspective we should really work on the Mentor activity then the "voting" problem
becomes minor.
I have no opinion of whether ASF Members should be allowed to simply step into IPMC or not
(Members should be expected to bring everything which is needed for a valuable decision making,
I guess).
But, I think its to "easy" to become mentor of a project.
So I would rather argue that not each IPMC member should automatically become a possible Mentor.
To become Mentor should be based on the experience / track record in "the apache way" as already
stated by others like Sheng.

Also I think our current practice of just saying "Interesting project, count me in as Mentor"
is not good as this leads exactly to the situation I described above.
So I would suggest to make the Mentor assignment somewhat binding, e.g. by IPMC Vote or some
other process and to force in the "activity" of mentors.
I have no detailed idea how this should be done but if Mentors regularily do not vote on Podling
releases and do not signoff podling reports this is a sign that perhaps another mentor has
to step in.
If we ensure that each podling always has 3 ACTIVE mentors, than most IPMC Release Votes become
LAZY votes.

This should, from my perspective, be the main goal to focus on.

Julian

Am 10.08.19, 13:55 schrieb "sebb" <sebbaz@gmail.com>:

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

Mime
View raw message