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" <seb...@gmail.com>:
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
