You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Justin Mclean <ju...@classsoftware.com> on 2019/08/09 05:04:14 UTC
[DISCUSS] IPMC votes on releases
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
Re: [DISCUSS] IPMC votes on releases
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> 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.
I like the idea but this wouldn’t be in line with the current ASF bylaws. I think they would need to be changed for this to happen.
> 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?
Only about 10%(?) of podlings manage to get 3 +1 votes from mentors/IPMC members on their dev lists. even podlings with 3 active mentors can’t always get 3 +1 votes, some podlings have 6 mentors and still can’t get 3 +1 votes on their releases..
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] IPMC votes on releases
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> 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.
Sadly only about 10% of votes come to the incubator with 3 +1 IPMC votes, even on projects with three or more active mentors not all vote for a number of reasons.
> So from my perspective we should really work on the Mentor activity then the "voting" problem becomes minor.
It's certainly an issue, it improved a lot of the last few years but mentors could still be more involved in some projects.
> 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.
It can do yes.
> 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.
Reports signing off is tracked. I use to keep track on inactive mentors, there's a strong correlation between not been active and not signing off 3 reports in a row, Also if mentors are missing podlings can put that in their report (there’s a question on that) and ask for more mentors.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] IPMC votes on releases
Posted by Julian Feinauer <j....@pragmaticminds.de>.
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" <se...@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 <ju...@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
Re: [DISCUSS] IPMC votes on releases
Posted by Justin Mclean <ju...@me.com>.
Hi,
> 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?
Yep they count.
> Do they really have to re-affirm their votes?
It’s good if they do but not a requirement, it’s best of the email contains how many IPMC votes they already have.
Thanks,
Justin
Re: [DISCUSS] IPMC votes on releases
Posted by sebb <se...@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 <ju...@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
Re: [DISCUSS] IPMC votes on releases
Posted by Paul King <pa...@asert.com.au>.
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 <ju...@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
>
>
Re: [DISCUSS] IPMC votes on releases
Posted by Felix Cheung <fe...@apache.org>.
option (D) combined with (E)
And encourage mentors to vote on dev@ makes sense to me
On Fri, Aug 9, 2019 at 3:24 PM Justin Mclean <ju...@me.com> wrote:
> Hi,
>
> > (D) will still require 2 more IPMC vote?
> > (E) will be like (B) in that it will need mentors or other IPMC to vote
> in
> > podling dev@?
>
> All releases require 3 (or more) +1 votes by a PMC so yes they would
> require 3 IPMC votes.
>
> Thanks,
> Justin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: [DISCUSS] IPMC votes on releases
Posted by Justin Mclean <ju...@me.com>.
Hi,
> (D) will still require 2 more IPMC vote?
> (E) will be like (B) in that it will need mentors or other IPMC to vote in
> podling dev@?
All releases require 3 (or more) +1 votes by a PMC so yes they would require 3 IPMC votes.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] IPMC votes on releases
Posted by Felix Cheung <fe...@apache.org>.
(D) will still require 2 more IPMC vote?
(E) will be like (B) in that it will need mentors or other IPMC to vote in
podling dev@?
On Thu, Aug 8, 2019 at 10:04 PM Justin Mclean <ju...@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
>
>
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on
releases)
Posted by Dave Fisher <wa...@apache.org>.
> On Aug 14, 2019, at 3:59 AM, Greg Stein <gs...@gmail.com> wrote:
>
> On Mon, Aug 12, 2019, 22:31 David Nalley <da...@gnsa.us> wrote:
>> ...
>
>> Greg - I propose that you, Ross (sorry for volunteering you), and I
>> pick an incubating project in need of mentor attention and make this
>> as streamlined as we can. Let's focus on educating and enabling and
>> not gatekeeping. Let's prove out the concept and stop beating this
>> poor horse so much. :)
>>
>
> This is not possible under the rules regime of the IPMC. A new PMC,
> operating under different rules, sanctioned by the Board, is required. With
> that, I am willing.
Apache Welcome? I’d join a new Incubator. Discuss at Apachecon NA?
Regards,
Dave
>
> Cheers,
> -g
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
Posted by Greg Stein <gs...@gmail.com>.
On Mon, Aug 12, 2019, 22:31 David Nalley <da...@gnsa.us> wrote:
>...
> Greg - I propose that you, Ross (sorry for volunteering you), and I
> pick an incubating project in need of mentor attention and make this
> as streamlined as we can. Let's focus on educating and enabling and
> not gatekeeping. Let's prove out the concept and stop beating this
> poor horse so much. :)
>
This is not possible under the rules regime of the IPMC. A new PMC,
operating under different rules, sanctioned by the Board, is required. With
that, I am willing.
Cheers,
-g
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on
releases)
Posted by Ross Gardler <rg...@outlook.com>.
I see I was volunteer... OK let's do it.
---
Sent from my phone, you know what that means - sorry
________________________________
From: David Nalley <da...@gnsa.us>
Sent: Monday, August 12, 2019 8:31:29 PM
To: general@incubator.apache.org <ge...@incubator.apache.org>
Subject: Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
>
> I'd like to see the IPMC get out of the way of the podlings' releases. I
> see no reason for us to be a gate, and many more reasons to back off and
> let podlings get their work done.
>
I strongly agree with your sentiment, even if I differ with your tactics a bit.
I think that they are releases (e.g. we the foundation accrues a bit
of risk when releasing, and in turn shield our contributors from risk
as we've promised) Obviously we aren't claiming that they are perfect
apache releases that meet the minimum apache guidelines for
cleanliness) and that we should recognize that risk by having the fact
that they are incubating clearly in the name. (Oh wait, we already do
that.) We also have the new disclaimer in there for good measure.
This, IMO, exposes the ASF to a very (teensy weensy) slight increase
in risk, but for a much greater community gain. We have DMCA safe
harbor process to shield us from a good deal of the risk. The podling
gets to move faster, and hopefully learn and grow faster in the
process.
Failure isn't the problem, IMO. In fact we should be pushing people to
fail faster, so that each time the release gets a little better, and
each time the community grows, and more people understand the
processes and problems.
Greg - I propose that you, Ross (sorry for volunteering you), and I
pick an incubating project in need of mentor attention and make this
as streamlined as we can. Let's focus on educating and enabling and
not gatekeeping. Let's prove out the concept and stop beating this
poor horse so much. :)
--David
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
Posted by David Nalley <da...@gnsa.us>.
>
> I'd like to see the IPMC get out of the way of the podlings' releases. I
> see no reason for us to be a gate, and many more reasons to back off and
> let podlings get their work done.
>
I strongly agree with your sentiment, even if I differ with your tactics a bit.
I think that they are releases (e.g. we the foundation accrues a bit
of risk when releasing, and in turn shield our contributors from risk
as we've promised) Obviously we aren't claiming that they are perfect
apache releases that meet the minimum apache guidelines for
cleanliness) and that we should recognize that risk by having the fact
that they are incubating clearly in the name. (Oh wait, we already do
that.) We also have the new disclaimer in there for good measure.
This, IMO, exposes the ASF to a very (teensy weensy) slight increase
in risk, but for a much greater community gain. We have DMCA safe
harbor process to shield us from a good deal of the risk. The podling
gets to move faster, and hopefully learn and grow faster in the
process.
Failure isn't the problem, IMO. In fact we should be pushing people to
fail faster, so that each time the release gets a little better, and
each time the community grows, and more people understand the
processes and problems.
Greg - I propose that you, Ross (sorry for volunteering you), and I
pick an incubating project in need of mentor attention and make this
as streamlined as we can. Let's focus on educating and enabling and
not gatekeeping. Let's prove out the concept and stop beating this
poor horse so much. :)
--David
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
Posted by Matt Sicker <bo...@gmail.com>.
We were handling votes like that in OpenWhisk up until graduation. Mentor
votes carry over to the IPMC vote.
On Mon, Aug 12, 2019 at 07:20, Jim Jagielski <ji...@jagunet.com> wrote:
> We have always had a mindset that we (the foundation) want to make it as
> "brain dead easy" for people to download, use, and consume ASF projects.
> This means that they don't need to worry about compliance, IP provenance,
> etc.
>
> Incubator releases are a special case. The expectation is, and should be,
> that these releases may have issues. In fact, it is quite likely they will.
> Again, as long as those downloading these releases are aware of that, and
> we've done all we could to ensure that they are aware of it, then we have
> satisfied our requirements. IMO, with the naming and the DISCLAIMER and
> other such touches, we are achieving that.
>
> And they are, in fact, *releases*. We need to recall that one function of
> the foundation, and PMCs, is to provide legal protection to those who are
> creating the software artifacts, and when a release is done, as a "formal"
> act of the foundation (via the PMC), it is when they legal coverage is at
> its most clear and explicit. So in order for those within the podling to
> enjoy the legal protection this foundation exists to provide, these do need
> to be releases. I would be opposed to not providing such coverage for those
> in our podlings, since they should be safe spaces to learn about the Apache
> Way and how to build communities and how to release software.
>
> This does NOT mean that the IPMC should be gatekeepers though... Just as
> PMC chairs are the "eyes and ears of the board", mentors are the "eyes and
> ears of the IPMC". The IPMC "vote" should be little more than a formality.
> IMO, if mentors are IPMC members, and there are at least 3 binding votes on
> the podling list, and the mentors are acting as IPMC members when they
> vote, then any other additional vote in the IPMC is not required... in
> essence, consider it like extending the vote for a lazy consensus, so to
> speak:
>
>
> "The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and
> pointers here). We have 3 (or more) binding votes from mentors. We are
> giving the IPMC and additional 72 hours to vote on said release."
>
> Comments?
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
> --
Matt Sicker <bo...@gmail.com>
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on
releases)
Posted by Jim Jagielski <ji...@jaguNET.com>.
No, I don't mean to blame the mentors... It is a hard job, mostly uncelebrated and thankless and the 1st place people point to when problems arise.
Also, in general, most mentors are those who suffer from volunteeritis and tend to bite off more than they can chew. But the reality is that they have signed up and that the podling does need them and depend on them. There is no shame in saying "I need to resign as mentor... I just don't have the time anymore".
Agreed, BTW, that the Champion role needs to be really emphasized...
> On Aug 12, 2019, at 1:22 PM, Dave Fisher <wa...@apache.org> wrote:
>
>
>
>> On Aug 12, 2019, at 9:24 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
>>
>>
>>
>>> On Aug 12, 2019, at 10:44 AM, Ted Dunning <te...@gmail.com> wrote:
>>>
>>> On Mon, Aug 12, 2019 at 5:20 AM Jim Jagielski <ji...@jagunet.com> wrote:
>>>
>>>> ...
>>>> This does NOT mean that the IPMC should be gatekeepers though... Just as
>>>> PMC chairs are the "eyes and ears of the board", mentors are the "eyes and
>>>> ears of the IPMC". The IPMC "vote" should be little more than a formality.
>>>> IMO, if mentors are IPMC members, and there are at least 3 binding votes on
>>>> the podling list, and the mentors are acting as IPMC members when they
>>>> vote, then any other additional vote in the IPMC is not required... in
>>>> essence, consider it like extending the vote for a lazy consensus, so to
>>>> speak:
>>>>
>>>>
>>>> "The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and
>>>> pointers here). We have 3 (or more) binding votes from mentors. We are
>>>> giving the IPMC and additional 72 hours to vote on said release."
>>>>
>>>
>>>
>>> This is good in theory, but as Justin has pointed out, 90% of podling
>>> releases don't have enough mentor votes to follow this path.
>>>
>>> The 10% that do have enough votes can easily follow this process.
>>
>> Then the ones that don't have enough mentors still require the 3 +1 binding votes. The idea is that if the podling already has it, then the IPMC "vote" is more procedural than anything else. If they don't, then either the mentors need to step up or the IPMC fills in the gap.
>>
>> The goal is to avoid having the Incubator be a gate-keeper.
>
> You state here the paradox if the podling does not have enough engaged mentors then the IPMC is the effective gateway.
>
> FWIW - there are currently 47 Podlings[1] and 85 Mentors. [2] There are several mentors who mentor 4-6 podlings. I’ve done the analysis before, but it breaks down to about half the mentors having only a single Podling and a quarter with only two.
>
> Also, let’s not blame the mentors as a lot of times a podling has trouble establishing themselves and the mentors move on for various reasons. Typically mentors are all volunteers. (That some are paid by a third party is perfectly fine.)
>
> Do we need more mentors? Sure. We do have over 10% of the membership mentoring and up to 30% on the IPMC. I sent a request to members@ some six months ago and I think we got two or three.
>
> Regards,
> Dave
>
> [1] http://incubator.apache.org/clutch/#clutch <http://incubator.apache.org/clutch/#clutch>
> [2] http://incubator.apache.org/clutch/#mentors <http://incubator.apache.org/clutch/#mentors>
>
>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org <ma...@incubator.apache.org>
>> For additional commands, e-mail: general-help@incubator.apache.org <ma...@incubator.apache.org>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org <ma...@incubator.apache.org>
> For additional commands, e-mail: general-help@incubator.apache.org <ma...@incubator.apache.org>
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on
releases)
Posted by Dave Fisher <wa...@apache.org>.
> On Aug 12, 2019, at 9:24 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
>
>
>
>> On Aug 12, 2019, at 10:44 AM, Ted Dunning <te...@gmail.com> wrote:
>>
>> On Mon, Aug 12, 2019 at 5:20 AM Jim Jagielski <ji...@jagunet.com> wrote:
>>
>>> ...
>>> This does NOT mean that the IPMC should be gatekeepers though... Just as
>>> PMC chairs are the "eyes and ears of the board", mentors are the "eyes and
>>> ears of the IPMC". The IPMC "vote" should be little more than a formality.
>>> IMO, if mentors are IPMC members, and there are at least 3 binding votes on
>>> the podling list, and the mentors are acting as IPMC members when they
>>> vote, then any other additional vote in the IPMC is not required... in
>>> essence, consider it like extending the vote for a lazy consensus, so to
>>> speak:
>>>
>>>
>>> "The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and
>>> pointers here). We have 3 (or more) binding votes from mentors. We are
>>> giving the IPMC and additional 72 hours to vote on said release."
>>>
>>
>>
>> This is good in theory, but as Justin has pointed out, 90% of podling
>> releases don't have enough mentor votes to follow this path.
>>
>> The 10% that do have enough votes can easily follow this process.
>
> Then the ones that don't have enough mentors still require the 3 +1 binding votes. The idea is that if the podling already has it, then the IPMC "vote" is more procedural than anything else. If they don't, then either the mentors need to step up or the IPMC fills in the gap.
>
> The goal is to avoid having the Incubator be a gate-keeper.
You state here the paradox if the podling does not have enough engaged mentors then the IPMC is the effective gateway.
FWIW - there are currently 47 Podlings[1] and 85 Mentors. [2] There are several mentors who mentor 4-6 podlings. I’ve done the analysis before, but it breaks down to about half the mentors having only a single Podling and a quarter with only two.
Also, let’s not blame the mentors as a lot of times a podling has trouble establishing themselves and the mentors move on for various reasons. Typically mentors are all volunteers. (That some are paid by a third party is perfectly fine.)
Do we need more mentors? Sure. We do have over 10% of the membership mentoring and up to 30% on the IPMC. I sent a request to members@ some six months ago and I think we got two or three.
Regards,
Dave
[1] http://incubator.apache.org/clutch/#clutch
[2] http://incubator.apache.org/clutch/#mentors
> ---------------------------------------------------------------------
> 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
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on
releases)
Posted by Ross Gardler <rg...@outlook.com>.
When I used to do endless apache way talks I used to say "if you are using an Incubator project expect to invest in both engineering and legal, but once a project is a TLP your legal can reduce and engineering becomes about your use rather than community progrwe towards TLP"
In other words Jim is right IMHO
---
Sent from my phone, you know what that means - sorry
________________________________
From: Dave Fisher <wa...@apache.org>
Sent: Tuesday, August 13, 2019 9:22:26 AM
To: general <ge...@incubator.apache.org>
Subject: Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
Hi Ted,
This subthread as named by Greg is really about this:
> On Aug 11, 2019, at 5:56 PM, Greg Stein <gs...@gmail.com> wrote:
>
> See further below for an unfortunately trimmed thread. A couple paragraphs
> that I wrote early-thread are important to add:
>
> ----
> Option (F): stop calling them official ASF releases, which means PMC votes
> are not required.
> ——
I am for option (F) with the addition of Myrle’s [REVIEW] until such time as the podling is fully compliant with Apache Release Policy and goes through the usual process. Abiding by the Apache Release Policy would remain a Graduation Requirement.
So, we treat these releases as not fully approved the same way we treat Binary Conveniences.
I think that this pattern grows the PPMC into a true PMC better by expecting that licensing issues which require vigilance become part of the Project’s DNA in a more organic way.
Regards,
Dave
> On Aug 13, 2019, at 9:09 AM, Ted Dunning <te...@gmail.com> wrote:
>
> Dave,
>
> I understand the problem with long delays. What I don't understand is how
> the proposal changes any of that.
>
> 90% of project release still require additional votes. How will that change?
>
> Every other change is peripheral.
>
>
>
> On Tue, Aug 13, 2019 at 8:37 AM Dave Fisher <wa...@apache.org> wrote:
>
>>
>>
>>> On Aug 12, 2019, at 1:34 PM, Ted Dunning <te...@gmail.com> wrote:
>>>
>>> On Mon, Aug 12, 2019 at 11:10 AM Dave Fisher <wave@apache.org <mailto:
>> wave@apache.org>> wrote:
>>>
>>>>
>>>>
>>>>> On Aug 12, 2019, at 10:02 AM, Ted Dunning <te...@gmail.com>
>> wrote:
>>>>>
>>>>> On Mon, Aug 12, 2019 at 9:24 AM Jim Jagielski <ji...@jagunet.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>>> On Aug 12, 2019, at 10:44 AM, Ted Dunning <te...@gmail.com>
>>>> wrote:
>>>>>> ...
>>>>>>>> "The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and
>>>>>>>> pointers here). We have 3 (or more) binding votes from mentors. We
>> are
>>>>>>>> giving the IPMC and additional 72 hours to vote on said release."
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> This is good in theory, but as Justin has pointed out, 90% of podling
>>>>>>> releases don't have enough mentor votes to follow this path.
>>>>>>>
>>>>>>> The 10% that do have enough votes can easily follow this process.
>>>>>>
>>>>>> Then the ones that don't have enough mentors still require the 3 +1
>>>>>> binding votes. The idea is that if the podling already has it, then
>> the
>>>>>> IPMC "vote" is more procedural than anything else. If they don't, then
>>>>>> either the mentors need to step up or the IPMC fills in the gap.
>>>>>>
>>>>>> The goal is to avoid having the Incubator be a gate-keeper.
>>>>>>
>>>>>
>>>>>
>>>>> I don't understand how this is all that different from what we have
>> now.
>>>> If
>>>>> three mentors (and thus IPMC members) vote yes, then opening up the
>> vote
>>>> to
>>>>> include the IPMC is just like what you said, "we have three votes
>> already
>>>>> and unless somebody points out something heinous, this is going to be a
>>>>> release". Whether the IPMC is a gatekeeper or a rubber stamp in these
>>>> cases
>>>>> is a tiny matter of nomenclature because the effect is typically a
>> rubber
>>>>> stamp (although some of these releases are examined carefully and
>> things
>>>>> turn up).
>>>>>
>>>>> In the large majority of cases, the Incubator is definitely not a
>>>>> gatekeeper. If anything, the non-mentor IPMC votes are enablers that
>>>> allow
>>>>> a release to go forward when it would otherwise fail.
>>>>
>>>> A week or two (an uncertain time) to do release votes as opposed to what
>>>> may already be a significant increase to a minimum 3 days will FEEL
>> like a
>>>> closed GATE. (For example Zipkin really felt gated.)
>>>>
>>>
>>>
>>>
>>> Dave,
>>>
>>> I don't understand your point.
>>
>> My point is that what you describe below are the ideal results. We all
>> know that while the podling itself can do release votes in 72 hours it
>> often takes the IPMC much more than 72 hours to vote. It used to be weeks
>> and has improved significantly to where most podlings can be done inside of
>> one week.
>>
>> The timing and uncertainty of this is too much for some previously
>> established communities. For instance I think that this indeterminate lag
>> is one of the causes that made Zipkin a poor fit here.
>>
>> We've relaxed DISCLAIMERs. Should we wait to see if this improves the
>> situation, or should we do another small step and essentially follow
>> Myrle’s Review plan[1] for all general@ votes?
>>
>> Regards,
>> Dave
>>
>> [1]
>> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread.html%2F495ed84b43c1ba2662075a6c8c869bcd337b6bf4bc1895149c1483de%40%253Cgeneral.incubator.apache.org%253E&data=02%7C01%7C%7Caab64e7826a14f92ed3508d7200a71b9%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637013101534070713&sdata=zrEMkadVkFV5QIJ1uKenqFGaWvpae%2F6ofq3T%2FOXjWS4%3D&reserved=0
>>
>>>
>>> Currently, a podling does a vote. If they (it does happen, but rarely)
>> get
>>> 3 mentor votes, then they can immediately call for comments / votes on
>> the
>>> IPMC list. If nothing bad turns up, they are done.
>>>
>>> If something really bad gets found at that point, it isn't the fault of
>> the
>>> process. It is the nature of release votes with different people looking
>> at
>>> different things. Further, a release wouldn't necessarily be blocked at
>>> that point, but if the problem really is bad, then it is good practice
>> for
>>> all +1 votes to switch to -1 so the vote fails and a new candidate can be
>>> rolled.
>>>
>>> The proposal Jim made said that there would be 72 additional hours to
>>> review after the vote passes the podling vote. It may be that there is a
>>> suggestion that this additional 72 hours could start immediately upon
>>> getting three mentor votes but this is very much a corner case since it
>>> would be a fraction of the 10% of the time that three mentors actually do
>>> vote. If the three mentors take a day or two to vote, then the only
>>> difference in the 10% case is a day or so acceleration.
>>>
>>> This just doesn't sound like it helps all that much. It changes 3 days +
>> 3
>>> days into 3 days + 3 days 90% of the time and has some potential to
>> change
>>> it into 3 days + 1-2 days less than 10% of the time.
>>>
>>> That is my point. Either I completely misunderstand what is being
>> proposed
>>> or it doesn't really make a significant difference. If I misunderstood, I
>>> would love to hear how and it seems like it would good to improve the
>>> description of the change. If it doesn't matter, we can make the change
>> or
>>> not and there shouldn't be much argument either way (because it doesn't
>>> matter).
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on
releases)
Posted by Justin Mclean <ju...@me.com>.
Hi,
As an aside for any project looking for mentors you can see what projects they mentor at teh bottom of this page:
https://incubator.apache.org/clutch/
And you can also check if they have been signing off reports here (if you are an ASF member or IPMC member):
https://whimsy.apache.org/incubator/signoff.cgi
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
Posted by Ted Dunning <te...@gmail.com>.
A vanity mentor is a person with a big name and a small amount of time.
Projects go for the name, the mentor goes for the ego boost and then
reality catches up. But, hey, you are "mentoring" 12 projects!
On Tue, Aug 13, 2019 at 5:18 PM David Jencks <da...@gmail.com>
wrote:
> What’s a “vanity mentor“? How do I recognize one before a podling has a
> significant history? Who is currently accepting these vanity mentors and
> how would they stop doing so?
>
> Hindsight is 20-20... I have no crystal ball.
>
> David Jencks
>
> Sent from my iPhone
>
> > On Aug 13, 2019, at 5:10 PM, Justin Mclean <ju...@classsoftware.com>
> wrote:
> >
> > Hi,
> >
> >> Here's an idea... The IPMC focuses on supporting mentors to do their
> job rather than forcing project developers and their mentors to jump
> through arbitrarily defined hoops.
> >
> > What "arbitrarily defined hoops” are you referring to? ASF policy or
> something else?
> >
> >> The IPMC doesn't need to enforce policy of any kind, except at the
> point of graduation.
> >
> > That seems less than ideal to me, why would a IPMC volunteer want to do
> that job? And again IMO it introduces a hard gate that podlings are going
> to dislike, probably more so than they do now.
> >
> >> When things change for individuals and they can no longer be good
> mentors then the IPMC needs to make it a priority to help find a new,
> truly dedicated mentor. It's a problem that needs to be solved, but let's
> worry about that when it's actually a problem rather than a hypothetical
> one.
> >
> > It’s currently a problem, not a hypothetical, see for instance votes
> coming to this list without 3 mentors +1 votes, or the missing reports or
> missing sign-offs on the current incubator report to the board. This
> problem isn’t going unrecognised either, you’ll also note that recently
> nearly every month new mentors have been found and added to podlings that
> need them.
> >
> > Thanks,
> > Justin
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
Posted by David Jencks <da...@gmail.com>.
What’s a “vanity mentor“? How do I recognize one before a podling has a significant history? Who is currently accepting these vanity mentors and how would they stop doing so?
Hindsight is 20-20... I have no crystal ball.
David Jencks
Sent from my iPhone
> On Aug 13, 2019, at 5:10 PM, Justin Mclean <ju...@classsoftware.com> wrote:
>
> Hi,
>
>> Here's an idea... The IPMC focuses on supporting mentors to do their job rather than forcing project developers and their mentors to jump through arbitrarily defined hoops.
>
> What "arbitrarily defined hoops” are you referring to? ASF policy or something else?
>
>> The IPMC doesn't need to enforce policy of any kind, except at the point of graduation.
>
> That seems less than ideal to me, why would a IPMC volunteer want to do that job? And again IMO it introduces a hard gate that podlings are going to dislike, probably more so than they do now.
>
>> When things change for individuals and they can no longer be good mentors then the IPMC needs to make it a priority to help find a new, truly dedicated mentor. It's a problem that needs to be solved, but let's worry about that when it's actually a problem rather than a hypothetical one.
>
> It’s currently a problem, not a hypothetical, see for instance votes coming to this list without 3 mentors +1 votes, or the missing reports or missing sign-offs on the current incubator report to the board. This problem isn’t going unrecognised either, you’ll also note that recently nearly every month new mentors have been found and added to podlings that need them.
>
> Thanks,
> Justin
>
>
>
> ---------------------------------------------------------------------
> 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
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on
releases)
Posted by Jim Jagielski <ji...@jaguNET.com>.
FTR: I think the biggest risk to the foundation are not these procedural aspects, like releases, but the gradual but inexorable decline in our culture and our principles. That is, or at least should be, the bigger concern. And I think the Incubator should take that risk much more seriously and to heart.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on
releases)
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Aug 14, 2019, at 1:24 AM, Dave Fisher <wa...@comcast.net> wrote:
>
>>>
>>> Q: Does the IPMC want to produce non-ASF releases?
>
> My answer is yes! I want podlings to be on a path towards graduation! I recognize multiple requirements. The path may differ for each podling. I’m the end there are two outcomes!
>
What does it mean to be a "non-ASF release"?
To be clear: I want, when podlings do releases, that all podling members enjoy the legal protections inherent in doing a s/w release that all other people enjoy when *they* do a release. That is only possible if those releases are ASF releases. Heck, I would say that having protection at this stage is likely more important, and likely more needed, than when subversion, for example, does one.
HOWEVER, those releases are specifically noted as likely being of varying quality and compliance as typical ASF releases from TLP/PMCs.
So legally, they should be ASF releases. Culturally, and expectation-wise, they are non-typical releases.
Again, the Incubator is, or at least should be, a safe space where communities can learn about the Apache Way, and how to build communities and how to develop software and how to do releases... All of that stuff is inherently risky. That's what the Incubator is also there to do: assume that risk so that podlings can learn to the point where they can assume their own risk. This does not mean, however, that the Incubator should be constantly getting in the way of podlings, using risk-abatement as the reason for gatekeeping.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
Posted by Dave Fisher <wa...@comcast.net>.
>>
>> Q: Does the IPMC want to produce non-ASF releases?
My answer is yes! I want podlings to be on a path towards graduation! I recognize multiple requirements. The path may differ for each podling. I’m the end there are two outcomes!
Thanks Greg!
Regards,
Dave
>>
>> -g
>
>
> ---------------------------------------------------------------------
> 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
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
Posted by Dave Fisher <wa...@comcast.net>.
Sent from my iPhone
> On Aug 13, 2019, at 9:32 PM, Greg Stein <gs...@gmail.com> wrote:
>
> On Tue, Aug 13, 2019 at 8:17 PM Justin Mclean <ju...@classsoftware.com>
> wrote:
>
>> Hi,
>>
>>> Hoops constructed by the IPMC. Like a secondary release vote on general@
>>
>> This is because of ASF bylaws i.e only PMC votes are binding on releases.
>
>
> That is not in the Bylaws. Stop making stuff up.
>
>
>> So you're saying implementations of ASF bylaws are "arbitrarily defined
>> hoops”?
>
>
> See above.
>
>
>> There could be other ways of dealing with this bylaw that have been
>> suggested,
>
>
> What bylaw? Got a reference?
>
>
>> for example treating podling releases not as official Apache releases.
>
>
> That is the origin of this thread, because you only ever pose
> hypotheticals. You only pose "could" possibilities. But you *never* move
> things to conclusion. So this thread is an attempt to do so.
>
> Your "could" emails on this thread is antithetical to its origin.
>
>
>> But that also has implications and concerns, which I’m not seeing being
>> addressed in this discussion.
>>
>
> Then help drive it, rather than take a back seat. Drive a decision.
>
> Q: Does the IPMC want to produce non-ASF releases?
>
> -g
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
Posted by Sam Ruby <ru...@intertwingly.net>.
On Wed, Aug 14, 2019 at 9:47 PM Justin Mclean <ju...@classsoftware.com> wrote:
>
> Hi
>
> Thanks for the idea and offer of help.
>
> > 1) Concurrent with the start of a release vote by a PPMC, the IPMC is
> > to be notified that that vote is happening. IPMC members are
> > encouraged to participate in the vote process on the PPMC list where
> > it is happening.
>
> This has been discussed before and I’m not sure the IPMC has the bandwidth for this. Most releases go through a couple RCs, sometime that can be more. This would be asking the IPMC to potentially review 3x-5x the number of releases than it normally done.
>
> > 3) If the PPMC vote completes before there is a call for an IPMC vote,
> > the PPMC is free to make the release.
>
> How does fit with the requirement that 3 +1 PMC votes needed for a release? Or is it doing away with it?
Sorry for being unclear. My suggestion was that the IPMC only votes
in the exceptional case where an IPMC member requests a vote. My
assertion is that oversight and the opportunity to intercede when
needed is sufficient.
> Thanks,
> Justin
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on
releases)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi
Thanks for the idea and offer of help.
> 1) Concurrent with the start of a release vote by a PPMC, the IPMC is
> to be notified that that vote is happening. IPMC members are
> encouraged to participate in the vote process on the PPMC list where
> it is happening.
This has been discussed before and I’m not sure the IPMC has the bandwidth for this. Most releases go through a couple RCs, sometime that can be more. This would be asking the IPMC to potentially review 3x-5x the number of releases than it normally done.
> 3) If the PPMC vote completes before there is a call for an IPMC vote,
> the PPMC is free to make the release.
How does fit with the requirement that 3 +1 PMC votes needed for a release? Or is it doing away with it?
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on
releases)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> That Infra and the board will allow a podling to put packages containing the WIP-disclaimer on dist.a.o as long as those packages
Infra have already confirmed that’s OK, legal have said it OK with some conditions, including if incubator releases are considered special. There is a proposal in the incubator board report to do this, hopefully the board will accept it.
> This new disclaimer should allow mentors to allow the podlings to publish packages for their users the way they probably did before entering incubation.
Not quite, but it does relax things, see [1]
> The podlings will have the option to push the packages to dist.a.o and then, if they want the legal shield protection, call for a vote from the IPMC if they don't have 3 mentor votes.
I’m not sure this should be optional, or up to the PPMC to decide, but it's an interesting idea to consider. Reason being is that the PPMC may not be in the best position (being new to the ASF) to recognise what the risk is. I’m not sure what the risk is or how (or if at all) it might impact on the insurance.
> The key risk here is whether the WIP disclaimer will help ward off possible legal action by a user of the package.
A disclaimer ultimately is probably no protection. For instance, you can’t put up a sign in a shop that says “No Refunds” when you have a right to a refund under consumer law. But I think the intention is clear that podlings what to do the right thing.
> The new disclaimer should greatly reduce the chances of a -1 vote. Instead, issues found will be logged in the podling's bug tracker.
Yep that was the whole idea.
> Practically speaking, if Justin is one of the 3 mentors, the podiing is probably in good shape heading towards graduation, of not, it probably is a good idea to get Justin to review the packages at some point.
Well the objective should be learn how to review releases on their own, rather than rely on me to check it for you, as you’re going to have to do that as a TLP.
> It was this late gate which was stricter with the old disclaimer that was the problem for Zipkin.
There were a larger number of issue steer as well. (Also while in incubation Zipkin made non offical releases.)
Thanks,
Justin
1. https://issues.apache.org/jira/browse/LEGAL-469
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on
releases)
Posted by Alex Harui <ah...@adobe.com.INVALID>.
IMO, the key change as already been made: There is now a WIP-disclaimer.
AFAICT, the rest of this thread has been an attempt to create an objective process around a subjective topic (in this case risk). The better use of time may be to just launch an experiment by making the one change suggested by Greg: That Infra and the board will allow a podling to put packages containing the WIP-disclaimer on dist.a.o as long as those packages also include "-incubating" or "-incubator" in the package name.
IMO, if that can be agreed to by the stakeholders, those stakeholders are agreeing that any risks to the foundation and RMs posed by Justin are worth taking and we can hopefully just move on and find out what happens.
Ideally, the WIP-disclaimer makes the IPMC vote:
1) optional
2) helpful
3) advisory
...instead of "potentially blocking".
This new disclaimer should allow mentors to allow the podlings to publish packages for their users the way they probably did before entering incubation. The podlings will have the option to push the packages to dist.a.o and then, if they want the legal shield protection, call for a vote from the IPMC if they don't have 3 mentor votes. The key risk here is whether the WIP disclaimer will help ward off possible legal action by a user of the package. IOW, is it too risky that something really awful will be missed by the mentors and PPMC in these packages? I doubt it. There might be GPL or proprietary code that needs to be replaced eventually. But the new disclaimer helps and I just think folks aren't going to try to sue the ASF or a podling RM during this transition period.
If a podling is lucky enough to have 3 mentors review the packages, then that should make those packages an official ASF release and thus protect the RM. If there aren't 3 mentors reviewing the packages, then the podling will have a reason to call for an IPMC vote to get the 3 votes. The new disclaimer should greatly reduce the chances of a -1 vote. Instead, issues found will be logged in the podling's bug tracker.
If the 3 mentors are certain enough of their review of the packages, then the podling can go on its merry way towards graduation. Otherwise, the podling should call for additional IPMC reviews of their packages in order to avoid major surprises before graduation. They just don't need to do it prior to publishing their packages, which makes the IPMC review helpful and advisory instead of potentially blocking. Yeah, there is a risk that a published package will be so awful it needs to be pulled in spite of the new disclaimer, but IMO, there is always a chance we've missed something. Practically speaking, if Justin is one of the 3 mentors, the podiing is probably in good shape heading towards graduation, of not, it probably is a good idea to get Justin to review the packages at some point.
IMO, it shouldn't take a special team of Greg/Ross/David to do this experiment. As long as podlings can publish before the vote/review, and the new disclaimer makes the chance of pulling something back almost zero, every podling can choose this new route and the IPMC vote will rarely if ever be a gate. It was this late gate which was stricter with the old disclaimer that was the problem for Zipkin.
HTH,
-Alex
On 8/14/19, 8:50 AM, "Sam Ruby" <ru...@intertwingly.net> wrote:
On Wed, Aug 14, 2019 at 1:24 AM Justin Mclean <ju...@classsoftware.com> wrote:
>
> Hi,
>
> >> This is because of ASF bylaws i.e only PMC votes are binding on releases.
> >
> > That is not in the Bylaws. Stop making stuff up.
>
> That the way it’s been explained to me, several times, by experienced ASF people, that only PMC votes are binding on releases and podlings are not mentioned in the ASF bylaws. Bylaw wise see section 6.3. But you're right, it would be more precise to say, it's a combination of 6.3 of the bylaws of the ASF and the ASF's policy on voting on releases. [1]
Concrete suggestion, and an offer to help.
The ASF bylaws contain a lot of curiosities such as "each member of a
Project Management Committee shall serve on such committee for a
period of one year or until his or her successor is elected and
qualified or until his or her earlier resignation or removal", and
have been interpreted as the board is the one that determines
membership of PMCs. Over time, that understanding has evolved, and is
currently implemented as a notification requirement[2].
Perhaps something similar can be made to work here. Outline of
proposed process:
1) Concurrent with the start of a release vote by a PPMC, the IPMC is
to be notified that that vote is happening. IPMC members are
encouraged to participate in the vote process on the PPMC list where
it is happening.
2) If anybody on the IPMC calls for a IPMC vote on the release before
the release occurs, then the release is blocked from happening until
this vote completes.
3) If the PPMC vote completes before there is a call for an IPMC vote,
the PPMC is free to make the release.
If such a process were in place, then the burden on the PPMC would be
normally be reduced to a single email per release. Any IPMC member
could still -- for any reason -- call for a full IPMC vote, but my
sense is that that rarely will happen, and when it does, it will
generally be because there is a substantive issue that needs to be
resolved.
If something like this were adopted by the IPMC, I will offer to help
update [1] to reflect that a different process applies during
incubation.
- Sam Ruby
[1] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apache.org%2Ffoundation%2Fvoting.html%23ReleaseVotes&data=02%7C01%7Caharui%40adobe.com%7Ce6aeb72c7a74453596e008d720cf1bb5%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637013946217354854&sdata=KNUMV3cXlX6jtTmRJ6qSIoM7YCWgPMGEeWeee1DWWpA%3D&reserved=0
[2] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhimsy.apache.org%2Fboard%2Fminutes%2FPMC_Membership_Change_Process.html&data=02%7C01%7Caharui%40adobe.com%7Ce6aeb72c7a74453596e008d720cf1bb5%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637013946217354854&sdata=oPC65Uuo7FAPb181b5yr1W17X7NszX%2FLM4ojDhxyVho%3D&reserved=0
---------------------------------------------------------------------
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
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
Posted by Sam Ruby <ru...@intertwingly.net>.
On Wed, Aug 14, 2019 at 1:24 AM Justin Mclean <ju...@classsoftware.com> wrote:
>
> Hi,
>
> >> This is because of ASF bylaws i.e only PMC votes are binding on releases.
> >
> > That is not in the Bylaws. Stop making stuff up.
>
> That the way it’s been explained to me, several times, by experienced ASF people, that only PMC votes are binding on releases and podlings are not mentioned in the ASF bylaws. Bylaw wise see section 6.3. But you're right, it would be more precise to say, it's a combination of 6.3 of the bylaws of the ASF and the ASF's policy on voting on releases. [1]
Concrete suggestion, and an offer to help.
The ASF bylaws contain a lot of curiosities such as "each member of a
Project Management Committee shall serve on such committee for a
period of one year or until his or her successor is elected and
qualified or until his or her earlier resignation or removal", and
have been interpreted as the board is the one that determines
membership of PMCs. Over time, that understanding has evolved, and is
currently implemented as a notification requirement[2].
Perhaps something similar can be made to work here. Outline of
proposed process:
1) Concurrent with the start of a release vote by a PPMC, the IPMC is
to be notified that that vote is happening. IPMC members are
encouraged to participate in the vote process on the PPMC list where
it is happening.
2) If anybody on the IPMC calls for a IPMC vote on the release before
the release occurs, then the release is blocked from happening until
this vote completes.
3) If the PPMC vote completes before there is a call for an IPMC vote,
the PPMC is free to make the release.
If such a process were in place, then the burden on the PPMC would be
normally be reduced to a single email per release. Any IPMC member
could still -- for any reason -- call for a full IPMC vote, but my
sense is that that rarely will happen, and when it does, it will
generally be because there is a substantive issue that needs to be
resolved.
If something like this were adopted by the IPMC, I will offer to help
update [1] to reflect that a different process applies during
incubation.
- Sam Ruby
[1] https://www.apache.org/foundation/voting.html#ReleaseVotes
[2] https://whimsy.apache.org/board/minutes/PMC_Membership_Change_Process.html
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on
releases)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
>> This is because of ASF bylaws i.e only PMC votes are binding on releases.
>
> That is not in the Bylaws. Stop making stuff up.
That the way it’s been explained to me, several times, by experienced ASF people, that only PMC votes are binding on releases and podlings are not mentioned in the ASF bylaws. Bylaw wise see section 6.3. But you're right, it would be more precise to say, it's a combination of 6.3 of the bylaws of the ASF and the ASF's policy on voting on releases. [1]
> That is the origin of this thread, because you only ever pose
> hypotheticals. You only pose "could" possibilities. But you *never* move
> things to conclusion.
I’ve done far more than just propose possibilities. If that is not evident on this list I suggest you read the last dozen incubator board reports for evidence. Is it just that’s the conclusion is not what you want or is it that it moving slower than you would like? Consensus in the IPMC is sometimes hard to reach, but don’t you think is worth trying to do that and engage in dialogue, rather than talking what seems on face value to me a rather combative position?
Thanks,
Justin
1. https://www.apache.org/foundation/voting.html#ReleaseVotes
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
Posted by Greg Stein <gs...@gmail.com>.
On Wed, Aug 14, 2019, 06:00 Julian Feinauer <j....@pragmaticminds.de>
wrote:
> Hi Greg,
>
> I think Justins Answer refers to the WIP-Disclaimer
Aware of that, but disagree. It is way more: the IPMC vote is performed to
establish legal oversight and shield. I suggest that is burdensome and
should be tossed.
PS.: Allow me to add a very personal side note. But it seems to me that the
> tone in this discussion is from time to time rather harsh.
And I add to the harsh. Yes. Guilty. ... But it makes me angry to see
misleading comments, and misdirection, away from the intent of my emails.
Cheers,
-g
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on
releases)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
I’m not referring to a recent thing, I’m referring to in part to this [1]. I suggest you read what Mark wrote there, but even before this JIRA many Apache podlings have made non-offical releases for a number of reasons some in line with policy (and some not). I can point you to one podling that made 100+ releases in this this way.
Greg if you persist in this behaviour I’ll need to refer you to the code of conduct, in particular you need to show a little more empathy for people who may not hold the same views as yourself, and it would also help if you tried to collaborate with other IPMC members and be more careful in the words you chose.
Thanks,
Justin
1. https://issues.apache.org/jira/browse/LEGAL-427
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on
releases)
Posted by Julian Feinauer <j....@pragmaticminds.de>.
Hi Greg,
I think Justins Answer refers to the WIP-Disclaimer which was recently added to the incubator Policy Page:
https://incubator.apache.org/policy/incubation.html#disclaimers
A Podlings releasing with the WIP Disclaimer is no ASF release, so I consider Justins response is no misdirection and I would also agree on that.
Julian
PS.: Allow me to add a very personal side note. But it seems to me that the tone in this discussion is from time to time rather harsh. I know that many people here have a long history in the ASF and with each other but it just doesn’t seem right that two very seasoned and well established ASF mentors consider that one of them straight lies on purpose on a ML, which makes me a bit sad : /
Am 14.08.19, 12:51 schrieb "Greg Stein" <gs...@gmail.com>:
On Wed, Aug 14, 2019, 00:33 Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
> > Q: Does the IPMC want to produce non-ASF releases?
>
> A: We already are
Not true, as you well know. Whether we call the above a lie, or
misdirection is left to the reader.
The IPMC currently attempts to ensure all podling releases conform to
policy, and then/thus calls them ASF releases.
This thread is to ask about stopping that approach. That we can/should make
a business decision to accept the moot risk of placing podling releases on
our distribution servers.
-g
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
Posted by Greg Stein <gs...@gmail.com>.
On Wed, Aug 14, 2019, 00:33 Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
> > Q: Does the IPMC want to produce non-ASF releases?
>
> A: We already are
Not true, as you well know. Whether we call the above a lie, or
misdirection is left to the reader.
The IPMC currently attempts to ensure all podling releases conform to
policy, and then/thus calls them ASF releases.
This thread is to ask about stopping that approach. That we can/should make
a business decision to accept the moot risk of placing podling releases on
our distribution servers.
-g
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on
releases)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Q: Does the IPMC want to produce non-ASF releases?
A: We already are, but there are some constraints around what to calling them, branding and when they can be placed. (And these are not IPMC policies.)
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Aug 13, 2019 at 8:17 PM Justin Mclean <ju...@classsoftware.com>
wrote:
> Hi,
>
> > Hoops constructed by the IPMC. Like a secondary release vote on general@
>
> This is because of ASF bylaws i.e only PMC votes are binding on releases.
That is not in the Bylaws. Stop making stuff up.
> So you're saying implementations of ASF bylaws are "arbitrarily defined
> hoops”?
See above.
> There could be other ways of dealing with this bylaw that have been
> suggested,
What bylaw? Got a reference?
> for example treating podling releases not as official Apache releases.
That is the origin of this thread, because you only ever pose
hypotheticals. You only pose "could" possibilities. But you *never* move
things to conclusion. So this thread is an attempt to do so.
Your "could" emails on this thread is antithetical to its origin.
> But that also has implications and concerns, which I’m not seeing being
> addressed in this discussion.
>
Then help drive it, rather than take a back seat. Drive a decision.
Q: Does the IPMC want to produce non-ASF releases?
-g
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on
releases)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Hoops constructed by the IPMC. Like a secondary release vote on general@
This is because of ASF bylaws i.e only PMC votes are binding on releases. So you're saying implementations of ASF bylaws are "arbitrarily defined hoops”? There could be other ways of dealing with this bylaw that have been suggested, for example treating podling releases not as official Apache releases. But that also has implications and concerns, which I’m not seeing being addressed in this discussion.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on
releases)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> They are gated day by day by day. Empirically, we already know the podlings
> dislike this.
Empirically? I would say it’s more anecdotally, (and the anonymous podling survey has actually never brought this up as an issue), and “day by day by day” is an exaggeration. Other than the occasional -1 on a release (which is not a veto) how else does the IPMC gate podlings other than at graduation? We could ask all of the current podlings in a more formal way and see what they do think which might be helpful? And/or as was also suggested try this out with a couple of podlings as an experiment and see what happens. Perhaps a first step is to ask for a podling/mentors to volunteer for this?
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Aug 13, 2019 at 7:10 PM Justin Mclean <ju...@classsoftware.com>
wrote:
> Hi,
>
> > Here's an idea... The IPMC focuses on supporting mentors to do their job
> rather than forcing project developers and their mentors to jump through
> arbitrarily defined hoops.
>
> What "arbitrarily defined hoops” are you referring to? ASF policy or
> something else?
>
Hoops constructed by the IPMC. Like a secondary release vote on general@
> > The IPMC doesn't need to enforce policy of any kind, except at the
> point of graduation.
>
> That seems less than ideal to me, why would a IPMC volunteer want to do
> that job? And again IMO it introduces a hard gate that podlings are going
> to dislike, probably more so than they do now.
>
They are gated day by day by day. Empirically, we already know the podlings
dislike this.
Let the podlings do their work. And say "nope. can't graduate now." ...
until they can.
>...
Cheers,
-g
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on
releases)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Here's an idea... The IPMC focuses on supporting mentors to do their job rather than forcing project developers and their mentors to jump through arbitrarily defined hoops.
What "arbitrarily defined hoops” are you referring to? ASF policy or something else?
> The IPMC doesn't need to enforce policy of any kind, except at the point of graduation.
That seems less than ideal to me, why would a IPMC volunteer want to do that job? And again IMO it introduces a hard gate that podlings are going to dislike, probably more so than they do now.
> When things change for individuals and they can no longer be good mentors then the IPMC needs to make it a priority to help find a new, truly dedicated mentor. It's a problem that needs to be solved, but let's worry about that when it's actually a problem rather than a hypothetical one.
It’s currently a problem, not a hypothetical, see for instance votes coming to this list without 3 mentors +1 votes, or the missing reports or missing sign-offs on the current incubator report to the board. This problem isn’t going unrecognised either, you’ll also note that recently nearly every month new mentors have been found and added to podlings that need them.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on
releases)
Posted by Ross Gardler <rg...@outlook.com>.
Here's an idea... The IPMC focuses on supporting mentors to do their job rather than forcing project developers and their mentors to jump through arbitrarily defined hoops.
That means stay out of the way until the mentor asks for a graduation vote. The IPMC doesn't need to enforce policy of any kind, except at the point of graduation. Policy is set and enforced by VP Legal, infra marketing, trademarks etc. The mentor can work directly with them as necessary.
I know holding mentors accountable is a tough job in itself, but if we quit accepting vanity mentors and instead focus on supporting mentors who have a personal interest in the success of the podling it shouldn't be too hard.
When things change for individuals and they can no longer be good mentors then the IPMC needs to make it a priority to help find a new, truly dedicated mentor. It's a problem that needs to be solved, but let's worry about that when it's actually a problem rather than a hypothetical one.
Ross
---
Sent from my phone, you know what that means - sorry
________________________________
From: Justin Mclean <ju...@classsoftware.com>
Sent: Tuesday, August 13, 2019 3:04:46 PM
To: general@incubator.apache.org <ge...@incubator.apache.org>
Subject: Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
Hi,
> I am for option (F) with the addition of Myrle’s [REVIEW] until such time as the podling is fully compliant with Apache Release Policy and goes through the usual process. Abiding by the Apache Release Policy would remain a Graduation Requirement.
I’ll note not a single podling has asked for a [REVIEW].
> So, we treat these releases as not fully approved the same way we treat Binary Conveniences.
They are not the same as binary conveniences, as they are derived from a voted on approved release. Thinking about (F) if they are not official releases could a podling:
a) Call them Apache releases? (Not doing may have a number of implications including naming of artefacts, package names and the like),
b) Place tham on a download page on their ASF provided website? If so what would be required to make it clear they are not approved releases?
We might want to check with branding and legal and get their input on this.
My concerns are that:
a) As IPMC votes are not required, less IPMC people (including mentors) look at the releases or are less thorough in doing so, and things slip through
b) This become a hard gate at the worse time i.e. graduation. What happens if a community proposed graduation and it found it’s releases have serious issue?
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on
releases)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I am for option (F) with the addition of Myrle’s [REVIEW] until such time as the podling is fully compliant with Apache Release Policy and goes through the usual process. Abiding by the Apache Release Policy would remain a Graduation Requirement.
I’ll note not a single podling has asked for a [REVIEW].
> So, we treat these releases as not fully approved the same way we treat Binary Conveniences.
They are not the same as binary conveniences, as they are derived from a voted on approved release. Thinking about (F) if they are not official releases could a podling:
a) Call them Apache releases? (Not doing may have a number of implications including naming of artefacts, package names and the like),
b) Place tham on a download page on their ASF provided website? If so what would be required to make it clear they are not approved releases?
We might want to check with branding and legal and get their input on this.
My concerns are that:
a) As IPMC votes are not required, less IPMC people (including mentors) look at the releases or are less thorough in doing so, and things slip through
b) This become a hard gate at the worse time i.e. graduation. What happens if a community proposed graduation and it found it’s releases have serious issue?
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on
releases)
Posted by Dave Fisher <wa...@apache.org>.
Hi Ted,
This subthread as named by Greg is really about this:
> On Aug 11, 2019, at 5:56 PM, Greg Stein <gs...@gmail.com> wrote:
>
> See further below for an unfortunately trimmed thread. A couple paragraphs
> that I wrote early-thread are important to add:
>
> ----
> Option (F): stop calling them official ASF releases, which means PMC votes
> are not required.
> ——
I am for option (F) with the addition of Myrle’s [REVIEW] until such time as the podling is fully compliant with Apache Release Policy and goes through the usual process. Abiding by the Apache Release Policy would remain a Graduation Requirement.
So, we treat these releases as not fully approved the same way we treat Binary Conveniences.
I think that this pattern grows the PPMC into a true PMC better by expecting that licensing issues which require vigilance become part of the Project’s DNA in a more organic way.
Regards,
Dave
> On Aug 13, 2019, at 9:09 AM, Ted Dunning <te...@gmail.com> wrote:
>
> Dave,
>
> I understand the problem with long delays. What I don't understand is how
> the proposal changes any of that.
>
> 90% of project release still require additional votes. How will that change?
>
> Every other change is peripheral.
>
>
>
> On Tue, Aug 13, 2019 at 8:37 AM Dave Fisher <wa...@apache.org> wrote:
>
>>
>>
>>> On Aug 12, 2019, at 1:34 PM, Ted Dunning <te...@gmail.com> wrote:
>>>
>>> On Mon, Aug 12, 2019 at 11:10 AM Dave Fisher <wave@apache.org <mailto:
>> wave@apache.org>> wrote:
>>>
>>>>
>>>>
>>>>> On Aug 12, 2019, at 10:02 AM, Ted Dunning <te...@gmail.com>
>> wrote:
>>>>>
>>>>> On Mon, Aug 12, 2019 at 9:24 AM Jim Jagielski <ji...@jagunet.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>>> On Aug 12, 2019, at 10:44 AM, Ted Dunning <te...@gmail.com>
>>>> wrote:
>>>>>> ...
>>>>>>>> "The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and
>>>>>>>> pointers here). We have 3 (or more) binding votes from mentors. We
>> are
>>>>>>>> giving the IPMC and additional 72 hours to vote on said release."
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> This is good in theory, but as Justin has pointed out, 90% of podling
>>>>>>> releases don't have enough mentor votes to follow this path.
>>>>>>>
>>>>>>> The 10% that do have enough votes can easily follow this process.
>>>>>>
>>>>>> Then the ones that don't have enough mentors still require the 3 +1
>>>>>> binding votes. The idea is that if the podling already has it, then
>> the
>>>>>> IPMC "vote" is more procedural than anything else. If they don't, then
>>>>>> either the mentors need to step up or the IPMC fills in the gap.
>>>>>>
>>>>>> The goal is to avoid having the Incubator be a gate-keeper.
>>>>>>
>>>>>
>>>>>
>>>>> I don't understand how this is all that different from what we have
>> now.
>>>> If
>>>>> three mentors (and thus IPMC members) vote yes, then opening up the
>> vote
>>>> to
>>>>> include the IPMC is just like what you said, "we have three votes
>> already
>>>>> and unless somebody points out something heinous, this is going to be a
>>>>> release". Whether the IPMC is a gatekeeper or a rubber stamp in these
>>>> cases
>>>>> is a tiny matter of nomenclature because the effect is typically a
>> rubber
>>>>> stamp (although some of these releases are examined carefully and
>> things
>>>>> turn up).
>>>>>
>>>>> In the large majority of cases, the Incubator is definitely not a
>>>>> gatekeeper. If anything, the non-mentor IPMC votes are enablers that
>>>> allow
>>>>> a release to go forward when it would otherwise fail.
>>>>
>>>> A week or two (an uncertain time) to do release votes as opposed to what
>>>> may already be a significant increase to a minimum 3 days will FEEL
>> like a
>>>> closed GATE. (For example Zipkin really felt gated.)
>>>>
>>>
>>>
>>>
>>> Dave,
>>>
>>> I don't understand your point.
>>
>> My point is that what you describe below are the ideal results. We all
>> know that while the podling itself can do release votes in 72 hours it
>> often takes the IPMC much more than 72 hours to vote. It used to be weeks
>> and has improved significantly to where most podlings can be done inside of
>> one week.
>>
>> The timing and uncertainty of this is too much for some previously
>> established communities. For instance I think that this indeterminate lag
>> is one of the causes that made Zipkin a poor fit here.
>>
>> We've relaxed DISCLAIMERs. Should we wait to see if this improves the
>> situation, or should we do another small step and essentially follow
>> Myrle’s Review plan[1] for all general@ votes?
>>
>> Regards,
>> Dave
>>
>> [1]
>> https://lists.apache.org/thread.html/495ed84b43c1ba2662075a6c8c869bcd337b6bf4bc1895149c1483de@%3Cgeneral.incubator.apache.org%3E
>>
>>>
>>> Currently, a podling does a vote. If they (it does happen, but rarely)
>> get
>>> 3 mentor votes, then they can immediately call for comments / votes on
>> the
>>> IPMC list. If nothing bad turns up, they are done.
>>>
>>> If something really bad gets found at that point, it isn't the fault of
>> the
>>> process. It is the nature of release votes with different people looking
>> at
>>> different things. Further, a release wouldn't necessarily be blocked at
>>> that point, but if the problem really is bad, then it is good practice
>> for
>>> all +1 votes to switch to -1 so the vote fails and a new candidate can be
>>> rolled.
>>>
>>> The proposal Jim made said that there would be 72 additional hours to
>>> review after the vote passes the podling vote. It may be that there is a
>>> suggestion that this additional 72 hours could start immediately upon
>>> getting three mentor votes but this is very much a corner case since it
>>> would be a fraction of the 10% of the time that three mentors actually do
>>> vote. If the three mentors take a day or two to vote, then the only
>>> difference in the 10% case is a day or so acceleration.
>>>
>>> This just doesn't sound like it helps all that much. It changes 3 days +
>> 3
>>> days into 3 days + 3 days 90% of the time and has some potential to
>> change
>>> it into 3 days + 1-2 days less than 10% of the time.
>>>
>>> That is my point. Either I completely misunderstand what is being
>> proposed
>>> or it doesn't really make a significant difference. If I misunderstood, I
>>> would love to hear how and it seems like it would good to improve the
>>> description of the change. If it doesn't matter, we can make the change
>> or
>>> not and there shouldn't be much argument either way (because it doesn't
>>> matter).
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
Posted by Ted Dunning <te...@gmail.com>.
Dave,
I understand the problem with long delays. What I don't understand is how
the proposal changes any of that.
90% of project release still require additional votes. How will that change?
Every other change is peripheral.
On Tue, Aug 13, 2019 at 8:37 AM Dave Fisher <wa...@apache.org> wrote:
>
>
> > On Aug 12, 2019, at 1:34 PM, Ted Dunning <te...@gmail.com> wrote:
> >
> > On Mon, Aug 12, 2019 at 11:10 AM Dave Fisher <wave@apache.org <mailto:
> wave@apache.org>> wrote:
> >
> >>
> >>
> >>> On Aug 12, 2019, at 10:02 AM, Ted Dunning <te...@gmail.com>
> wrote:
> >>>
> >>> On Mon, Aug 12, 2019 at 9:24 AM Jim Jagielski <ji...@jagunet.com> wrote:
> >>>
> >>>>
> >>>>
> >>>>> On Aug 12, 2019, at 10:44 AM, Ted Dunning <te...@gmail.com>
> >> wrote:
> >>>> ...
> >>>>>> "The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and
> >>>>>> pointers here). We have 3 (or more) binding votes from mentors. We
> are
> >>>>>> giving the IPMC and additional 72 hours to vote on said release."
> >>>>>>
> >>>>>
> >>>>>
> >>>>> This is good in theory, but as Justin has pointed out, 90% of podling
> >>>>> releases don't have enough mentor votes to follow this path.
> >>>>>
> >>>>> The 10% that do have enough votes can easily follow this process.
> >>>>
> >>>> Then the ones that don't have enough mentors still require the 3 +1
> >>>> binding votes. The idea is that if the podling already has it, then
> the
> >>>> IPMC "vote" is more procedural than anything else. If they don't, then
> >>>> either the mentors need to step up or the IPMC fills in the gap.
> >>>>
> >>>> The goal is to avoid having the Incubator be a gate-keeper.
> >>>>
> >>>
> >>>
> >>> I don't understand how this is all that different from what we have
> now.
> >> If
> >>> three mentors (and thus IPMC members) vote yes, then opening up the
> vote
> >> to
> >>> include the IPMC is just like what you said, "we have three votes
> already
> >>> and unless somebody points out something heinous, this is going to be a
> >>> release". Whether the IPMC is a gatekeeper or a rubber stamp in these
> >> cases
> >>> is a tiny matter of nomenclature because the effect is typically a
> rubber
> >>> stamp (although some of these releases are examined carefully and
> things
> >>> turn up).
> >>>
> >>> In the large majority of cases, the Incubator is definitely not a
> >>> gatekeeper. If anything, the non-mentor IPMC votes are enablers that
> >> allow
> >>> a release to go forward when it would otherwise fail.
> >>
> >> A week or two (an uncertain time) to do release votes as opposed to what
> >> may already be a significant increase to a minimum 3 days will FEEL
> like a
> >> closed GATE. (For example Zipkin really felt gated.)
> >>
> >
> >
> >
> > Dave,
> >
> > I don't understand your point.
>
> My point is that what you describe below are the ideal results. We all
> know that while the podling itself can do release votes in 72 hours it
> often takes the IPMC much more than 72 hours to vote. It used to be weeks
> and has improved significantly to where most podlings can be done inside of
> one week.
>
> The timing and uncertainty of this is too much for some previously
> established communities. For instance I think that this indeterminate lag
> is one of the causes that made Zipkin a poor fit here.
>
> We've relaxed DISCLAIMERs. Should we wait to see if this improves the
> situation, or should we do another small step and essentially follow
> Myrle’s Review plan[1] for all general@ votes?
>
> Regards,
> Dave
>
> [1]
> https://lists.apache.org/thread.html/495ed84b43c1ba2662075a6c8c869bcd337b6bf4bc1895149c1483de@%3Cgeneral.incubator.apache.org%3E
>
> >
> > Currently, a podling does a vote. If they (it does happen, but rarely)
> get
> > 3 mentor votes, then they can immediately call for comments / votes on
> the
> > IPMC list. If nothing bad turns up, they are done.
> >
> > If something really bad gets found at that point, it isn't the fault of
> the
> > process. It is the nature of release votes with different people looking
> at
> > different things. Further, a release wouldn't necessarily be blocked at
> > that point, but if the problem really is bad, then it is good practice
> for
> > all +1 votes to switch to -1 so the vote fails and a new candidate can be
> > rolled.
> >
> > The proposal Jim made said that there would be 72 additional hours to
> > review after the vote passes the podling vote. It may be that there is a
> > suggestion that this additional 72 hours could start immediately upon
> > getting three mentor votes but this is very much a corner case since it
> > would be a fraction of the 10% of the time that three mentors actually do
> > vote. If the three mentors take a day or two to vote, then the only
> > difference in the 10% case is a day or so acceleration.
> >
> > This just doesn't sound like it helps all that much. It changes 3 days +
> 3
> > days into 3 days + 3 days 90% of the time and has some potential to
> change
> > it into 3 days + 1-2 days less than 10% of the time.
> >
> > That is my point. Either I completely misunderstand what is being
> proposed
> > or it doesn't really make a significant difference. If I misunderstood, I
> > would love to hear how and it seems like it would good to improve the
> > description of the change. If it doesn't matter, we can make the change
> or
> > not and there shouldn't be much argument either way (because it doesn't
> > matter).
>
>
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on
releases)
Posted by Dave Fisher <wa...@apache.org>.
> On Aug 12, 2019, at 1:34 PM, Ted Dunning <te...@gmail.com> wrote:
>
> On Mon, Aug 12, 2019 at 11:10 AM Dave Fisher <wave@apache.org <ma...@apache.org>> wrote:
>
>>
>>
>>> On Aug 12, 2019, at 10:02 AM, Ted Dunning <te...@gmail.com> wrote:
>>>
>>> On Mon, Aug 12, 2019 at 9:24 AM Jim Jagielski <ji...@jagunet.com> wrote:
>>>
>>>>
>>>>
>>>>> On Aug 12, 2019, at 10:44 AM, Ted Dunning <te...@gmail.com>
>> wrote:
>>>> ...
>>>>>> "The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and
>>>>>> pointers here). We have 3 (or more) binding votes from mentors. We are
>>>>>> giving the IPMC and additional 72 hours to vote on said release."
>>>>>>
>>>>>
>>>>>
>>>>> This is good in theory, but as Justin has pointed out, 90% of podling
>>>>> releases don't have enough mentor votes to follow this path.
>>>>>
>>>>> The 10% that do have enough votes can easily follow this process.
>>>>
>>>> Then the ones that don't have enough mentors still require the 3 +1
>>>> binding votes. The idea is that if the podling already has it, then the
>>>> IPMC "vote" is more procedural than anything else. If they don't, then
>>>> either the mentors need to step up or the IPMC fills in the gap.
>>>>
>>>> The goal is to avoid having the Incubator be a gate-keeper.
>>>>
>>>
>>>
>>> I don't understand how this is all that different from what we have now.
>> If
>>> three mentors (and thus IPMC members) vote yes, then opening up the vote
>> to
>>> include the IPMC is just like what you said, "we have three votes already
>>> and unless somebody points out something heinous, this is going to be a
>>> release". Whether the IPMC is a gatekeeper or a rubber stamp in these
>> cases
>>> is a tiny matter of nomenclature because the effect is typically a rubber
>>> stamp (although some of these releases are examined carefully and things
>>> turn up).
>>>
>>> In the large majority of cases, the Incubator is definitely not a
>>> gatekeeper. If anything, the non-mentor IPMC votes are enablers that
>> allow
>>> a release to go forward when it would otherwise fail.
>>
>> A week or two (an uncertain time) to do release votes as opposed to what
>> may already be a significant increase to a minimum 3 days will FEEL like a
>> closed GATE. (For example Zipkin really felt gated.)
>>
>
>
>
> Dave,
>
> I don't understand your point.
My point is that what you describe below are the ideal results. We all know that while the podling itself can do release votes in 72 hours it often takes the IPMC much more than 72 hours to vote. It used to be weeks and has improved significantly to where most podlings can be done inside of one week.
The timing and uncertainty of this is too much for some previously established communities. For instance I think that this indeterminate lag is one of the causes that made Zipkin a poor fit here.
We've relaxed DISCLAIMERs. Should we wait to see if this improves the situation, or should we do another small step and essentially follow Myrle’s Review plan[1] for all general@ votes?
Regards,
Dave
[1] https://lists.apache.org/thread.html/495ed84b43c1ba2662075a6c8c869bcd337b6bf4bc1895149c1483de@%3Cgeneral.incubator.apache.org%3E
>
> Currently, a podling does a vote. If they (it does happen, but rarely) get
> 3 mentor votes, then they can immediately call for comments / votes on the
> IPMC list. If nothing bad turns up, they are done.
>
> If something really bad gets found at that point, it isn't the fault of the
> process. It is the nature of release votes with different people looking at
> different things. Further, a release wouldn't necessarily be blocked at
> that point, but if the problem really is bad, then it is good practice for
> all +1 votes to switch to -1 so the vote fails and a new candidate can be
> rolled.
>
> The proposal Jim made said that there would be 72 additional hours to
> review after the vote passes the podling vote. It may be that there is a
> suggestion that this additional 72 hours could start immediately upon
> getting three mentor votes but this is very much a corner case since it
> would be a fraction of the 10% of the time that three mentors actually do
> vote. If the three mentors take a day or two to vote, then the only
> difference in the 10% case is a day or so acceleration.
>
> This just doesn't sound like it helps all that much. It changes 3 days + 3
> days into 3 days + 3 days 90% of the time and has some potential to change
> it into 3 days + 1-2 days less than 10% of the time.
>
> That is my point. Either I completely misunderstand what is being proposed
> or it doesn't really make a significant difference. If I misunderstood, I
> would love to hear how and it seems like it would good to improve the
> description of the change. If it doesn't matter, we can make the change or
> not and there shouldn't be much argument either way (because it doesn't
> matter).
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
Posted by Ted Dunning <te...@gmail.com>.
On Mon, Aug 12, 2019 at 11:10 AM Dave Fisher <wa...@apache.org> wrote:
>
>
> > On Aug 12, 2019, at 10:02 AM, Ted Dunning <te...@gmail.com> wrote:
> >
> > On Mon, Aug 12, 2019 at 9:24 AM Jim Jagielski <ji...@jagunet.com> wrote:
> >
> >>
> >>
> >>> On Aug 12, 2019, at 10:44 AM, Ted Dunning <te...@gmail.com>
> wrote:
> >> ...
> >>>> "The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and
> >>>> pointers here). We have 3 (or more) binding votes from mentors. We are
> >>>> giving the IPMC and additional 72 hours to vote on said release."
> >>>>
> >>>
> >>>
> >>> This is good in theory, but as Justin has pointed out, 90% of podling
> >>> releases don't have enough mentor votes to follow this path.
> >>>
> >>> The 10% that do have enough votes can easily follow this process.
> >>
> >> Then the ones that don't have enough mentors still require the 3 +1
> >> binding votes. The idea is that if the podling already has it, then the
> >> IPMC "vote" is more procedural than anything else. If they don't, then
> >> either the mentors need to step up or the IPMC fills in the gap.
> >>
> >> The goal is to avoid having the Incubator be a gate-keeper.
> >>
> >
> >
> > I don't understand how this is all that different from what we have now.
> If
> > three mentors (and thus IPMC members) vote yes, then opening up the vote
> to
> > include the IPMC is just like what you said, "we have three votes already
> > and unless somebody points out something heinous, this is going to be a
> > release". Whether the IPMC is a gatekeeper or a rubber stamp in these
> cases
> > is a tiny matter of nomenclature because the effect is typically a rubber
> > stamp (although some of these releases are examined carefully and things
> > turn up).
> >
> > In the large majority of cases, the Incubator is definitely not a
> > gatekeeper. If anything, the non-mentor IPMC votes are enablers that
> allow
> > a release to go forward when it would otherwise fail.
>
> A week or two (an uncertain time) to do release votes as opposed to what
> may already be a significant increase to a minimum 3 days will FEEL like a
> closed GATE. (For example Zipkin really felt gated.)
>
Dave,
I don't understand your point.
Currently, a podling does a vote. If they (it does happen, but rarely) get
3 mentor votes, then they can immediately call for comments / votes on the
IPMC list. If nothing bad turns up, they are done.
If something really bad gets found at that point, it isn't the fault of the
process. It is the nature of release votes with different people looking at
different things. Further, a release wouldn't necessarily be blocked at
that point, but if the problem really is bad, then it is good practice for
all +1 votes to switch to -1 so the vote fails and a new candidate can be
rolled.
The proposal Jim made said that there would be 72 additional hours to
review after the vote passes the podling vote. It may be that there is a
suggestion that this additional 72 hours could start immediately upon
getting three mentor votes but this is very much a corner case since it
would be a fraction of the 10% of the time that three mentors actually do
vote. If the three mentors take a day or two to vote, then the only
difference in the 10% case is a day or so acceleration.
This just doesn't sound like it helps all that much. It changes 3 days + 3
days into 3 days + 3 days 90% of the time and has some potential to change
it into 3 days + 1-2 days less than 10% of the time.
That is my point. Either I completely misunderstand what is being proposed
or it doesn't really make a significant difference. If I misunderstood, I
would love to hear how and it seems like it would good to improve the
description of the change. If it doesn't matter, we can make the change or
not and there shouldn't be much argument either way (because it doesn't
matter).
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on
releases)
Posted by Dave Fisher <wa...@apache.org>.
> On Aug 12, 2019, at 10:02 AM, Ted Dunning <te...@gmail.com> wrote:
>
> On Mon, Aug 12, 2019 at 9:24 AM Jim Jagielski <ji...@jagunet.com> wrote:
>
>>
>>
>>> On Aug 12, 2019, at 10:44 AM, Ted Dunning <te...@gmail.com> wrote:
>> ...
>>>> "The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and
>>>> pointers here). We have 3 (or more) binding votes from mentors. We are
>>>> giving the IPMC and additional 72 hours to vote on said release."
>>>>
>>>
>>>
>>> This is good in theory, but as Justin has pointed out, 90% of podling
>>> releases don't have enough mentor votes to follow this path.
>>>
>>> The 10% that do have enough votes can easily follow this process.
>>
>> Then the ones that don't have enough mentors still require the 3 +1
>> binding votes. The idea is that if the podling already has it, then the
>> IPMC "vote" is more procedural than anything else. If they don't, then
>> either the mentors need to step up or the IPMC fills in the gap.
>>
>> The goal is to avoid having the Incubator be a gate-keeper.
>>
>
>
> I don't understand how this is all that different from what we have now. If
> three mentors (and thus IPMC members) vote yes, then opening up the vote to
> include the IPMC is just like what you said, "we have three votes already
> and unless somebody points out something heinous, this is going to be a
> release". Whether the IPMC is a gatekeeper or a rubber stamp in these cases
> is a tiny matter of nomenclature because the effect is typically a rubber
> stamp (although some of these releases are examined carefully and things
> turn up).
>
> In the large majority of cases, the Incubator is definitely not a
> gatekeeper. If anything, the non-mentor IPMC votes are enablers that allow
> a release to go forward when it would otherwise fail.
A week or two (an uncertain time) to do release votes as opposed to what may already be a significant increase to a minimum 3 days will FEEL like a closed GATE. (For example Zipkin really felt gated.)
Regards,
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
Posted by Ted Dunning <te...@gmail.com>.
On Mon, Aug 12, 2019 at 9:24 AM Jim Jagielski <ji...@jagunet.com> wrote:
>
>
> > On Aug 12, 2019, at 10:44 AM, Ted Dunning <te...@gmail.com> wrote:
> ...
> >> "The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and
> >> pointers here). We have 3 (or more) binding votes from mentors. We are
> >> giving the IPMC and additional 72 hours to vote on said release."
> >>
> >
> >
> > This is good in theory, but as Justin has pointed out, 90% of podling
> > releases don't have enough mentor votes to follow this path.
> >
> > The 10% that do have enough votes can easily follow this process.
>
> Then the ones that don't have enough mentors still require the 3 +1
> binding votes. The idea is that if the podling already has it, then the
> IPMC "vote" is more procedural than anything else. If they don't, then
> either the mentors need to step up or the IPMC fills in the gap.
>
> The goal is to avoid having the Incubator be a gate-keeper.
>
I don't understand how this is all that different from what we have now. If
three mentors (and thus IPMC members) vote yes, then opening up the vote to
include the IPMC is just like what you said, "we have three votes already
and unless somebody points out something heinous, this is going to be a
release". Whether the IPMC is a gatekeeper or a rubber stamp in these cases
is a tiny matter of nomenclature because the effect is typically a rubber
stamp (although some of these releases are examined carefully and things
turn up).
In the large majority of cases, the Incubator is definitely not a
gatekeeper. If anything, the non-mentor IPMC votes are enablers that allow
a release to go forward when it would otherwise fail.
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on
releases)
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Aug 12, 2019, at 10:44 AM, Ted Dunning <te...@gmail.com> wrote:
>
> On Mon, Aug 12, 2019 at 5:20 AM Jim Jagielski <ji...@jagunet.com> wrote:
>
>> ...
>> This does NOT mean that the IPMC should be gatekeepers though... Just as
>> PMC chairs are the "eyes and ears of the board", mentors are the "eyes and
>> ears of the IPMC". The IPMC "vote" should be little more than a formality.
>> IMO, if mentors are IPMC members, and there are at least 3 binding votes on
>> the podling list, and the mentors are acting as IPMC members when they
>> vote, then any other additional vote in the IPMC is not required... in
>> essence, consider it like extending the vote for a lazy consensus, so to
>> speak:
>>
>>
>> "The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and
>> pointers here). We have 3 (or more) binding votes from mentors. We are
>> giving the IPMC and additional 72 hours to vote on said release."
>>
>
>
> This is good in theory, but as Justin has pointed out, 90% of podling
> releases don't have enough mentor votes to follow this path.
>
> The 10% that do have enough votes can easily follow this process.
Then the ones that don't have enough mentors still require the 3 +1 binding votes. The idea is that if the podling already has it, then the IPMC "vote" is more procedural than anything else. If they don't, then either the mentors need to step up or the IPMC fills in the gap.
The goal is to avoid having the Incubator be a gate-keeper.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on
releases)
Posted by Dave Fisher <wa...@apache.org>.
Hi -
> On Aug 12, 2019, at 8:44 AM, Julian Feinauer <j....@pragmaticminds.de> wrote:
>
> Hi Ted,
>
> dont get me wrong, I'm rather new to the ASF, the incubator and especially the IPMC. So my perspective might be different. But, I understand the frustration that some may have and I leant that there have been many trials to change things which didn’t go the way we wanted.
> The "fear" or concerns I have is that loosening some requirements feels a bit like resigning which would be a horrible thing as the incubator is one of the (if not the) most important projects in the ASF.
>
> And I don’t object that much with having different classes of releases (its not elegant but acceptable IMHO) but the thing I'm really concerned about is the lack of possibilities to learn for podlings.
> If we come at the end to the modus operandi of "Yeah, simply release as is but use this disclaimer or that NOTICE and later in the project we will do it 'right'" that would be pretty bad.
> But perhaps I'm too spoiled as I had the luck to be in several podlings with Justin and Chris Dutz who both took lots of time and did an excellent job in helping me and all other freshmen to really learn what this Apache Release policy is about and how to do it right.
> And this is something so important that I want every other podling / newcomers to the ASF to experience.
>
> I know that this might sound provocative and perhaps some people might disagree but perhaps, if we know that we have not enough "mentor-power" we should be more careful about picking up new projects in the incubator if we are not sure how to bring them to TLP successful?
We definitely do need to be more careful. I think that we need to empower and better define the Champion role so that two things are done:
(1) The Champion makes sure that the incoming project is truly on board. This means testing the incoming community both donor and the initial committer list that they understand how Apache Way governance works. This is more than release policy, it is about using the dev@ list to make asynchronous decisions within the podling community. I think that this does not happen enough and mentors lose track of podlings because they can’t see what is happening without being entwined in GitHub issues and commit emails.
(2) The Champion makes sure that there are enough Mentors who have taken a podling through the Incubator. A good mix of “Junior” Mentors like I was once and Julian is now is good, but having old veterans like Jim, Jean-Baptiste, Julian, Justin, and Bertrand among others is truly critical.
See [1] for a good graph showing the ebb and flow of Incubator podlings through time.
Regards,
Dave
[1] https://projects.apache.org
>
> Julian
>
> Am 12.08.19, 17:34 schrieb "Ted Dunning" <te...@gmail.com>:
>
> Julian,
>
> I love the sentiment, but increasing the probability of mentor-only
> approval by 10x is going to take a lot of something that we haven't had the
> last five times we have tried to do this. The current system is a bit
> frustrating, but having what amounts to mentors-at-large like Justin and a
> few others is the only way we have right now to solve the problem of
> inspecting releases (and helping to improve them).
>
> And regarding two level of artifacts, we already have two kinds of podling
> release artifacts. Those are releasable and defective (and thus not
> releasable). That can't change since it is inherent in the release ground
> rules and the fact that incoming podlings don't know the ground rules. The
> only change is to make the defective artifacts provisionally releasable.
>
>
>
> On Mon, Aug 12, 2019 at 7:56 AM Julian Feinauer <
> j.feinauer@pragmaticminds.de> wrote:
>
>> Hi Ted,
>>
>> but instead of questioning the Bylaws or introducing two classes of
>> artifacts I would rather try to improve mentor votes as this is something
>> we can do incubator internal.
>> And its always better to cure the cause then the symptoms : )
>>
>> Julian
>>
>> Am 12.08.19, 16:44 schrieb "Ted Dunning" <te...@gmail.com>:
>>
>> On Mon, Aug 12, 2019 at 5:20 AM Jim Jagielski <ji...@jagunet.com> wrote:
>>
>>> ...
>>> This does NOT mean that the IPMC should be gatekeepers though...
>> Just as
>>> PMC chairs are the "eyes and ears of the board", mentors are the
>> "eyes and
>>> ears of the IPMC". The IPMC "vote" should be little more than a
>> formality.
>>> IMO, if mentors are IPMC members, and there are at least 3 binding
>> votes on
>>> the podling list, and the mentors are acting as IPMC members when
>> they
>>> vote, then any other additional vote in the IPMC is not required...
>> in
>>> essence, consider it like extending the vote for a lazy consensus,
>> so to
>>> speak:
>>>
>>>
>>> "The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and
>>> pointers here). We have 3 (or more) binding votes from mentors. We
>> are
>>> giving the IPMC and additional 72 hours to vote on said release."
>>>
>>
>>
>> This is good in theory, but as Justin has pointed out, 90% of podling
>> releases don't have enough mentor votes to follow this path.
>>
>> The 10% that do have enough votes can easily follow this process.
>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> 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
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on
releases)
Posted by Julian Feinauer <j....@pragmaticminds.de>.
Hi Ted,
dont get me wrong, I'm rather new to the ASF, the incubator and especially the IPMC. So my perspective might be different. But, I understand the frustration that some may have and I leant that there have been many trials to change things which didn’t go the way we wanted.
The "fear" or concerns I have is that loosening some requirements feels a bit like resigning which would be a horrible thing as the incubator is one of the (if not the) most important projects in the ASF.
And I don’t object that much with having different classes of releases (its not elegant but acceptable IMHO) but the thing I'm really concerned about is the lack of possibilities to learn for podlings.
If we come at the end to the modus operandi of "Yeah, simply release as is but use this disclaimer or that NOTICE and later in the project we will do it 'right'" that would be pretty bad.
But perhaps I'm too spoiled as I had the luck to be in several podlings with Justin and Chris Dutz who both took lots of time and did an excellent job in helping me and all other freshmen to really learn what this Apache Release policy is about and how to do it right.
And this is something so important that I want every other podling / newcomers to the ASF to experience.
I know that this might sound provocative and perhaps some people might disagree but perhaps, if we know that we have not enough "mentor-power" we should be more careful about picking up new projects in the incubator if we are not sure how to bring them to TLP successful?
Julian
Am 12.08.19, 17:34 schrieb "Ted Dunning" <te...@gmail.com>:
Julian,
I love the sentiment, but increasing the probability of mentor-only
approval by 10x is going to take a lot of something that we haven't had the
last five times we have tried to do this. The current system is a bit
frustrating, but having what amounts to mentors-at-large like Justin and a
few others is the only way we have right now to solve the problem of
inspecting releases (and helping to improve them).
And regarding two level of artifacts, we already have two kinds of podling
release artifacts. Those are releasable and defective (and thus not
releasable). That can't change since it is inherent in the release ground
rules and the fact that incoming podlings don't know the ground rules. The
only change is to make the defective artifacts provisionally releasable.
On Mon, Aug 12, 2019 at 7:56 AM Julian Feinauer <
j.feinauer@pragmaticminds.de> wrote:
> Hi Ted,
>
> but instead of questioning the Bylaws or introducing two classes of
> artifacts I would rather try to improve mentor votes as this is something
> we can do incubator internal.
> And its always better to cure the cause then the symptoms : )
>
> Julian
>
> Am 12.08.19, 16:44 schrieb "Ted Dunning" <te...@gmail.com>:
>
> On Mon, Aug 12, 2019 at 5:20 AM Jim Jagielski <ji...@jagunet.com> wrote:
>
> > ...
> > This does NOT mean that the IPMC should be gatekeepers though...
> Just as
> > PMC chairs are the "eyes and ears of the board", mentors are the
> "eyes and
> > ears of the IPMC". The IPMC "vote" should be little more than a
> formality.
> > IMO, if mentors are IPMC members, and there are at least 3 binding
> votes on
> > the podling list, and the mentors are acting as IPMC members when
> they
> > vote, then any other additional vote in the IPMC is not required...
> in
> > essence, consider it like extending the vote for a lazy consensus,
> so to
> > speak:
> >
> >
> > "The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and
> > pointers here). We have 3 (or more) binding votes from mentors. We
> are
> > giving the IPMC and additional 72 hours to vote on said release."
> >
>
>
> This is good in theory, but as Justin has pointed out, 90% of podling
> releases don't have enough mentor votes to follow this path.
>
> The 10% that do have enough votes can easily follow this process.
>
>
>
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
Posted by Ted Dunning <te...@gmail.com>.
Julian,
I love the sentiment, but increasing the probability of mentor-only
approval by 10x is going to take a lot of something that we haven't had the
last five times we have tried to do this. The current system is a bit
frustrating, but having what amounts to mentors-at-large like Justin and a
few others is the only way we have right now to solve the problem of
inspecting releases (and helping to improve them).
And regarding two level of artifacts, we already have two kinds of podling
release artifacts. Those are releasable and defective (and thus not
releasable). That can't change since it is inherent in the release ground
rules and the fact that incoming podlings don't know the ground rules. The
only change is to make the defective artifacts provisionally releasable.
On Mon, Aug 12, 2019 at 7:56 AM Julian Feinauer <
j.feinauer@pragmaticminds.de> wrote:
> Hi Ted,
>
> but instead of questioning the Bylaws or introducing two classes of
> artifacts I would rather try to improve mentor votes as this is something
> we can do incubator internal.
> And its always better to cure the cause then the symptoms : )
>
> Julian
>
> Am 12.08.19, 16:44 schrieb "Ted Dunning" <te...@gmail.com>:
>
> On Mon, Aug 12, 2019 at 5:20 AM Jim Jagielski <ji...@jagunet.com> wrote:
>
> > ...
> > This does NOT mean that the IPMC should be gatekeepers though...
> Just as
> > PMC chairs are the "eyes and ears of the board", mentors are the
> "eyes and
> > ears of the IPMC". The IPMC "vote" should be little more than a
> formality.
> > IMO, if mentors are IPMC members, and there are at least 3 binding
> votes on
> > the podling list, and the mentors are acting as IPMC members when
> they
> > vote, then any other additional vote in the IPMC is not required...
> in
> > essence, consider it like extending the vote for a lazy consensus,
> so to
> > speak:
> >
> >
> > "The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and
> > pointers here). We have 3 (or more) binding votes from mentors. We
> are
> > giving the IPMC and additional 72 hours to vote on said release."
> >
>
>
> This is good in theory, but as Justin has pointed out, 90% of podling
> releases don't have enough mentor votes to follow this path.
>
> The 10% that do have enough votes can easily follow this process.
>
>
>
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on
releases)
Posted by Julian Feinauer <j....@pragmaticminds.de>.
Hi Ted,
but instead of questioning the Bylaws or introducing two classes of artifacts I would rather try to improve mentor votes as this is something we can do incubator internal.
And its always better to cure the cause then the symptoms : )
Julian
Am 12.08.19, 16:44 schrieb "Ted Dunning" <te...@gmail.com>:
On Mon, Aug 12, 2019 at 5:20 AM Jim Jagielski <ji...@jagunet.com> wrote:
> ...
> This does NOT mean that the IPMC should be gatekeepers though... Just as
> PMC chairs are the "eyes and ears of the board", mentors are the "eyes and
> ears of the IPMC". The IPMC "vote" should be little more than a formality.
> IMO, if mentors are IPMC members, and there are at least 3 binding votes on
> the podling list, and the mentors are acting as IPMC members when they
> vote, then any other additional vote in the IPMC is not required... in
> essence, consider it like extending the vote for a lazy consensus, so to
> speak:
>
>
> "The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and
> pointers here). We have 3 (or more) binding votes from mentors. We are
> giving the IPMC and additional 72 hours to vote on said release."
>
This is good in theory, but as Justin has pointed out, 90% of podling
releases don't have enough mentor votes to follow this path.
The 10% that do have enough votes can easily follow this process.
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
Posted by Ted Dunning <te...@gmail.com>.
On Mon, Aug 12, 2019 at 5:20 AM Jim Jagielski <ji...@jagunet.com> wrote:
> ...
> This does NOT mean that the IPMC should be gatekeepers though... Just as
> PMC chairs are the "eyes and ears of the board", mentors are the "eyes and
> ears of the IPMC". The IPMC "vote" should be little more than a formality.
> IMO, if mentors are IPMC members, and there are at least 3 binding votes on
> the podling list, and the mentors are acting as IPMC members when they
> vote, then any other additional vote in the IPMC is not required... in
> essence, consider it like extending the vote for a lazy consensus, so to
> speak:
>
>
> "The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and
> pointers here). We have 3 (or more) binding votes from mentors. We are
> giving the IPMC and additional 72 hours to vote on said release."
>
This is good in theory, but as Justin has pointed out, 90% of podling
releases don't have enough mentor votes to follow this path.
The 10% that do have enough votes can easily follow this process.
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on
releases)
Posted by Jim Jagielski <ji...@jaguNET.com>.
We have always had a mindset that we (the foundation) want to make it as "brain dead easy" for people to download, use, and consume ASF projects. This means that they don't need to worry about compliance, IP provenance, etc.
Incubator releases are a special case. The expectation is, and should be, that these releases may have issues. In fact, it is quite likely they will. Again, as long as those downloading these releases are aware of that, and we've done all we could to ensure that they are aware of it, then we have satisfied our requirements. IMO, with the naming and the DISCLAIMER and other such touches, we are achieving that.
And they are, in fact, *releases*. We need to recall that one function of the foundation, and PMCs, is to provide legal protection to those who are creating the software artifacts, and when a release is done, as a "formal" act of the foundation (via the PMC), it is when they legal coverage is at its most clear and explicit. So in order for those within the podling to enjoy the legal protection this foundation exists to provide, these do need to be releases. I would be opposed to not providing such coverage for those in our podlings, since they should be safe spaces to learn about the Apache Way and how to build communities and how to release software.
This does NOT mean that the IPMC should be gatekeepers though... Just as PMC chairs are the "eyes and ears of the board", mentors are the "eyes and ears of the IPMC". The IPMC "vote" should be little more than a formality. IMO, if mentors are IPMC members, and there are at least 3 binding votes on the podling list, and the mentors are acting as IPMC members when they vote, then any other additional vote in the IPMC is not required... in essence, consider it like extending the vote for a lazy consensus, so to speak:
"The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and pointers here). We have 3 (or more) binding votes from mentors. We are giving the IPMC and additional 72 hours to vote on said release."
Comments?
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on
releases)
Posted by Ross Gardler <ro...@gardler.me>.
Thanks Greg, I am fully in support of your position here.
The ASF is supposed to make it easier for developers to develop. It is not supposed to be creating red tape to guard the entrance to the hallowed halls.
Ross
________________________________________
From: Greg Stein <gs...@gmail.com>
Sent: Sunday, August 11, 2019 5:56 PM
To: general@incubator.apache.org
Subject: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
See further below for an unfortunately trimmed thread. A couple paragraphs
that I wrote early-thread are important to add:
----
Option (F): stop calling them official ASF releases, which means PMC votes
are not required.
----
> In that case voting would not be required and they wouldn’t have to follow
> ASF policy.
Right.
> If they are not official releases then we probably can’t release or
> distribute them on ASF infrastructure.
I see no problem with using our infrastructure to distribute F/OSS
materials. Why would the Foundation want to be against that? If it is
labeled properly, then ... roll with it. We distribute a *ton* of stuff
that wasn't produced by the ASF. We incorporate that stuff into a larger
work, but it isn't "ours". Yet we put it onto our servers.
Clearly, these bits and bobs and blobs *are* intended to be F/OSS. Maybe
somebody thinks a LICENSE file isn't correct, so maybe ACME Inc. can't use
it ... but John and Jane and Joe certainly want to, and *can*. Isn't that
our goal?
----
I see no problems with the purported "risk" mentioned below. Would some
mis-licensing occur? Likely. Is it material to the Foundation's mission?
Nah. What if something appears on our servers without a clear F/OSS
license? Does John or Jane care? Nopes. But we fix it in a future release.
Move along, everybody is happy.
I'd like to see the IPMC get out of the way of the podlings' releases. I
see no reason for us to be a gate, and many more reasons to back off and
let podlings get their work done.
Cheers,
-g
On Sun, Aug 11, 2019 at 7:46 PM Greg Stein <gs...@gmail.com> wrote:
> On Sun, Aug 11, 2019 at 6:32 AM Justin Mclean <ju...@classsoftware.com>
> wrote:
>
>> Hi,
>>
>> > I see no problem with using our infrastructure to distribute F/OSS
>> > materials. Why would the Foundation want to be against that? If it is
>> > labeled properly, then ... roll with it.
>>
>> It often isn’t labelled properly. There’s a reasonable risk that some of
>> what would be placed there and distributed isn’t actually F/OSS.
>
>
> And what would be the blowback of something on our server with incorrect
> information? Very little. Mostly, we'd just move on. Maybe we delete it.
>
>
>> I can point you to several example of this. I’m not sure how the
>> incubator (or the board) would feel about that risk, so that would be
>> something we would be need to consider further. Also
>
>
> Welp. Then I will pose that question, rather than this endless
> pontificating about "risk".
>
>
>> while Jane and John may be fine with that, a lot of companies that use
>> Apache releases may not be.
>>
>
> I already acknowledged that. Many people could use software regardless of
> its licensing. The license typically only matters in *redistribution*
> scenarios. Things like the AGPL affect *usage*, but that is very, very
> atypical. I'd think 99% of downstream could use our software, even with
> gummed-up licensing.
>
>
>> > You're conflating *learning* with *releases*. These can be handled
>> separately.
>>
>> How exactly?
>
>
> You're saying that releases are the control point to learning. I say just
> let the releases go.
>
> You want to teach? Then you can use the releases like "that wasn't good.
> next time: do A and B". Over time, releases will get fixed. But the IPMC
> should not have to manage the releases.
>
> Cheers,
> -g
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
Posted by Greg Stein <gs...@gmail.com>.
See further below for an unfortunately trimmed thread. A couple paragraphs
that I wrote early-thread are important to add:
----
Option (F): stop calling them official ASF releases, which means PMC votes
are not required.
----
> In that case voting would not be required and they wouldn’t have to follow
> ASF policy.
Right.
> If they are not official releases then we probably can’t release or
> distribute them on ASF infrastructure.
I see no problem with using our infrastructure to distribute F/OSS
materials. Why would the Foundation want to be against that? If it is
labeled properly, then ... roll with it. We distribute a *ton* of stuff
that wasn't produced by the ASF. We incorporate that stuff into a larger
work, but it isn't "ours". Yet we put it onto our servers.
Clearly, these bits and bobs and blobs *are* intended to be F/OSS. Maybe
somebody thinks a LICENSE file isn't correct, so maybe ACME Inc. can't use
it ... but John and Jane and Joe certainly want to, and *can*. Isn't that
our goal?
----
I see no problems with the purported "risk" mentioned below. Would some
mis-licensing occur? Likely. Is it material to the Foundation's mission?
Nah. What if something appears on our servers without a clear F/OSS
license? Does John or Jane care? Nopes. But we fix it in a future release.
Move along, everybody is happy.
I'd like to see the IPMC get out of the way of the podlings' releases. I
see no reason for us to be a gate, and many more reasons to back off and
let podlings get their work done.
Cheers,
-g
On Sun, Aug 11, 2019 at 7:46 PM Greg Stein <gs...@gmail.com> wrote:
> On Sun, Aug 11, 2019 at 6:32 AM Justin Mclean <ju...@classsoftware.com>
> wrote:
>
>> Hi,
>>
>> > I see no problem with using our infrastructure to distribute F/OSS
>> > materials. Why would the Foundation want to be against that? If it is
>> > labeled properly, then ... roll with it.
>>
>> It often isn’t labelled properly. There’s a reasonable risk that some of
>> what would be placed there and distributed isn’t actually F/OSS.
>
>
> And what would be the blowback of something on our server with incorrect
> information? Very little. Mostly, we'd just move on. Maybe we delete it.
>
>
>> I can point you to several example of this. I’m not sure how the
>> incubator (or the board) would feel about that risk, so that would be
>> something we would be need to consider further. Also
>
>
> Welp. Then I will pose that question, rather than this endless
> pontificating about "risk".
>
>
>> while Jane and John may be fine with that, a lot of companies that use
>> Apache releases may not be.
>>
>
> I already acknowledged that. Many people could use software regardless of
> its licensing. The license typically only matters in *redistribution*
> scenarios. Things like the AGPL affect *usage*, but that is very, very
> atypical. I'd think 99% of downstream could use our software, even with
> gummed-up licensing.
>
>
>> > You're conflating *learning* with *releases*. These can be handled
>> separately.
>>
>> How exactly?
>
>
> You're saying that releases are the control point to learning. I say just
> let the releases go.
>
> You want to teach? Then you can use the releases like "that wasn't good.
> next time: do A and B". Over time, releases will get fixed. But the IPMC
> should not have to manage the releases.
>
> Cheers,
> -g
>
>
Re: [DISCUSS] IPMC votes on releases
Posted by Dave Fisher <wa...@apache.org>.
Hi -
> On Aug 12, 2019, at 6:41 AM, Matt Sicker <bo...@gmail.com> wrote:
>
> This observer IPMC role sounds interesting. That would make it less
> intimidating for people who can help verify a generic release but are
> unfamiliar with the domain itself.
We currently have Shepherds to look into podlings at report time. This is for how they are doing in the community.
If we have an observer role, I don’t think it needs to be formal. It would simply be to be a freelance release auditor. Perhaps those people willing to be an extra IPMC on a community dev@ vote could subscribe to a special mailing list. When a podling starts a release and suspects they don’t have enough Mentors engaged they can send a email to reviews@incubator.apache.org requesting help. (Some might say use general@ that’s ok too.)
This is similar to Mryle’s REVIEW proposal. It just becomes about timing.
Also, if a podling regularly has trouble with enough IPMC votes for their dev@ releases then a discussion is needed about finding new volunteer mentors.
Regards,
Dave
>
> On Mon, Aug 12, 2019 at 03:37, Julian Feinauer <j....@pragmaticminds.de>
> wrote:
>
>> Hi,
>>
>> I'm answering to this (old) thread as the new one branched up with a
>> different topic.
>> Personally, during my time in the first podling I learned a lot by doing
>> Apache Releases.
>> First, as contributor, then as PPMC and finally as RM.
>> And this is something valuable and if a project wants to become a TLP
>> something people have to learn.
>> And not only one or two but better every PPMC member (and some even able
>> to RM).
>>
>> So I suggest to encourage Podlings as much as possible to to ASF releases.
>> I would suggest to solve all the current issues by setting the rules up in
>> a way which lets podlings have (at least) 3 +1 IPMC votes in their PPMC
>> Vote which are then carried over and make the IPMC Vote basically "lazy
>> consensus".
>>
>> To do this I would suggest to set up / change the "Mentor Guideline" that
>> a Mentor "should" vote on PPMC releases.
>> Furthermore, in addition to 3 (active?!) Mentors we could add 2-3
>> "assessors" or "observers" (from the IPMC) who do not help actively but are
>> on the list and whos dutie is to support Releases.
>> That would make a pool of 5-6 IPMC members for each podling which should
>> be encouraged to VOTE on releases.
>>
>> Then, we could, step by step, tackle podlings to bring their Vote to the
>> IPMC only if they have 3 +1 votes.
>>
>> This would allow us to keep all global rules of the ASF as is and only
>> change Incubator "internals".
>> I think we should really start to see Mentoring as something which needs
>> time and work and which people should only call in if they feel like they
>> can do.
>> For everything else we could have this "observer" role where people that
>> find the project interesting could simply take to watch and monitor it but
>> with their Votes also help the incubator a lot.
>>
>> Julian
>>
>> Am 12.08.19, 02:46 schrieb "Greg Stein" <gs...@gmail.com>:
>>
>> On Sun, Aug 11, 2019 at 6:32 AM Justin Mclean <
>> justin@classsoftware.com>
>> wrote:
>>
>>> Hi,
>>>
>>>> I see no problem with using our infrastructure to distribute F/OSS
>>>> materials. Why would the Foundation want to be against that? If it
>> is
>>>> labeled properly, then ... roll with it.
>>>
>>> It often isn’t labelled properly. There’s a reasonable risk that
>> some of
>>> what would be placed there and distributed isn’t actually F/OSS.
>>
>>
>> And what would be the blowback of something on our server with
>> incorrect
>> information? Very little. Mostly, we'd just move on. Maybe we delete
>> it.
>>
>>
>>> I can point you to several example of this. I’m not sure how the
>> incubator
>>> (or the board) would feel about that risk, so that would be
>> something we
>>> would be need to consider further. Also
>>
>>
>> Welp. Then I will pose that question, rather than this endless
>> pontificating about "risk".
>>
>>
>>> while Jane and John may be fine with that, a lot of companies that
>> use
>>> Apache releases may not be.
>>>
>>
>> I already acknowledged that. Many people could use software regardless
>> of
>> its licensing. The license typically only matters in *redistribution*
>> scenarios. Things like the AGPL affect *usage*, but that is very, very
>> atypical. I'd think 99% of downstream could use our software, even with
>> gummed-up licensing.
>>
>>
>>>> You're conflating *learning* with *releases*. These can be handled
>>> separately.
>>>
>>> How exactly?
>>
>>
>> You're saying that releases are the control point to learning. I say
>> just
>> let the releases go.
>>
>> You want to teach? Then you can use the releases like "that wasn't
>> good.
>> next time: do A and B". Over time, releases will get fixed. But the
>> IPMC
>> should not have to manage the releases.
>>
>> Cheers,
>> -g
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
> --
> Matt Sicker <bo...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] IPMC votes on releases
Posted by Matt Sicker <bo...@gmail.com>.
This observer IPMC role sounds interesting. That would make it less
intimidating for people who can help verify a generic release but are
unfamiliar with the domain itself.
On Mon, Aug 12, 2019 at 03:37, Julian Feinauer <j....@pragmaticminds.de>
wrote:
> Hi,
>
> I'm answering to this (old) thread as the new one branched up with a
> different topic.
> Personally, during my time in the first podling I learned a lot by doing
> Apache Releases.
> First, as contributor, then as PPMC and finally as RM.
> And this is something valuable and if a project wants to become a TLP
> something people have to learn.
> And not only one or two but better every PPMC member (and some even able
> to RM).
>
> So I suggest to encourage Podlings as much as possible to to ASF releases.
> I would suggest to solve all the current issues by setting the rules up in
> a way which lets podlings have (at least) 3 +1 IPMC votes in their PPMC
> Vote which are then carried over and make the IPMC Vote basically "lazy
> consensus".
>
> To do this I would suggest to set up / change the "Mentor Guideline" that
> a Mentor "should" vote on PPMC releases.
> Furthermore, in addition to 3 (active?!) Mentors we could add 2-3
> "assessors" or "observers" (from the IPMC) who do not help actively but are
> on the list and whos dutie is to support Releases.
> That would make a pool of 5-6 IPMC members for each podling which should
> be encouraged to VOTE on releases.
>
> Then, we could, step by step, tackle podlings to bring their Vote to the
> IPMC only if they have 3 +1 votes.
>
> This would allow us to keep all global rules of the ASF as is and only
> change Incubator "internals".
> I think we should really start to see Mentoring as something which needs
> time and work and which people should only call in if they feel like they
> can do.
> For everything else we could have this "observer" role where people that
> find the project interesting could simply take to watch and monitor it but
> with their Votes also help the incubator a lot.
>
> Julian
>
> Am 12.08.19, 02:46 schrieb "Greg Stein" <gs...@gmail.com>:
>
> On Sun, Aug 11, 2019 at 6:32 AM Justin Mclean <
> justin@classsoftware.com>
> wrote:
>
> > Hi,
> >
> > > I see no problem with using our infrastructure to distribute F/OSS
> > > materials. Why would the Foundation want to be against that? If it
> is
> > > labeled properly, then ... roll with it.
> >
> > It often isn’t labelled properly. There’s a reasonable risk that
> some of
> > what would be placed there and distributed isn’t actually F/OSS.
>
>
> And what would be the blowback of something on our server with
> incorrect
> information? Very little. Mostly, we'd just move on. Maybe we delete
> it.
>
>
> > I can point you to several example of this. I’m not sure how the
> incubator
> > (or the board) would feel about that risk, so that would be
> something we
> > would be need to consider further. Also
>
>
> Welp. Then I will pose that question, rather than this endless
> pontificating about "risk".
>
>
> > while Jane and John may be fine with that, a lot of companies that
> use
> > Apache releases may not be.
> >
>
> I already acknowledged that. Many people could use software regardless
> of
> its licensing. The license typically only matters in *redistribution*
> scenarios. Things like the AGPL affect *usage*, but that is very, very
> atypical. I'd think 99% of downstream could use our software, even with
> gummed-up licensing.
>
>
> > > You're conflating *learning* with *releases*. These can be handled
> > separately.
> >
> > How exactly?
>
>
> You're saying that releases are the control point to learning. I say
> just
> let the releases go.
>
> You want to teach? Then you can use the releases like "that wasn't
> good.
> next time: do A and B". Over time, releases will get fixed. But the
> IPMC
> should not have to manage the releases.
>
> Cheers,
> -g
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
--
Matt Sicker <bo...@gmail.com>
Re: [DISCUSS] IPMC votes on releases
Posted by Julian Feinauer <j....@pragmaticminds.de>.
Hi,
I'm answering to this (old) thread as the new one branched up with a different topic.
Personally, during my time in the first podling I learned a lot by doing Apache Releases.
First, as contributor, then as PPMC and finally as RM.
And this is something valuable and if a project wants to become a TLP something people have to learn.
And not only one or two but better every PPMC member (and some even able to RM).
So I suggest to encourage Podlings as much as possible to to ASF releases.
I would suggest to solve all the current issues by setting the rules up in a way which lets podlings have (at least) 3 +1 IPMC votes in their PPMC Vote which are then carried over and make the IPMC Vote basically "lazy consensus".
To do this I would suggest to set up / change the "Mentor Guideline" that a Mentor "should" vote on PPMC releases.
Furthermore, in addition to 3 (active?!) Mentors we could add 2-3 "assessors" or "observers" (from the IPMC) who do not help actively but are on the list and whos dutie is to support Releases.
That would make a pool of 5-6 IPMC members for each podling which should be encouraged to VOTE on releases.
Then, we could, step by step, tackle podlings to bring their Vote to the IPMC only if they have 3 +1 votes.
This would allow us to keep all global rules of the ASF as is and only change Incubator "internals".
I think we should really start to see Mentoring as something which needs time and work and which people should only call in if they feel like they can do.
For everything else we could have this "observer" role where people that find the project interesting could simply take to watch and monitor it but with their Votes also help the incubator a lot.
Julian
Am 12.08.19, 02:46 schrieb "Greg Stein" <gs...@gmail.com>:
On Sun, Aug 11, 2019 at 6:32 AM Justin Mclean <ju...@classsoftware.com>
wrote:
> Hi,
>
> > I see no problem with using our infrastructure to distribute F/OSS
> > materials. Why would the Foundation want to be against that? If it is
> > labeled properly, then ... roll with it.
>
> It often isn’t labelled properly. There’s a reasonable risk that some of
> what would be placed there and distributed isn’t actually F/OSS.
And what would be the blowback of something on our server with incorrect
information? Very little. Mostly, we'd just move on. Maybe we delete it.
> I can point you to several example of this. I’m not sure how the incubator
> (or the board) would feel about that risk, so that would be something we
> would be need to consider further. Also
Welp. Then I will pose that question, rather than this endless
pontificating about "risk".
> while Jane and John may be fine with that, a lot of companies that use
> Apache releases may not be.
>
I already acknowledged that. Many people could use software regardless of
its licensing. The license typically only matters in *redistribution*
scenarios. Things like the AGPL affect *usage*, but that is very, very
atypical. I'd think 99% of downstream could use our software, even with
gummed-up licensing.
> > You're conflating *learning* with *releases*. These can be handled
> separately.
>
> How exactly?
You're saying that releases are the control point to learning. I say just
let the releases go.
You want to teach? Then you can use the releases like "that wasn't good.
next time: do A and B". Over time, releases will get fixed. But the IPMC
should not have to manage the releases.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] IPMC votes on releases
Posted by Greg Stein <gs...@gmail.com>.
On Sun, Aug 11, 2019 at 6:32 AM Justin Mclean <ju...@classsoftware.com>
wrote:
> Hi,
>
> > I see no problem with using our infrastructure to distribute F/OSS
> > materials. Why would the Foundation want to be against that? If it is
> > labeled properly, then ... roll with it.
>
> It often isn’t labelled properly. There’s a reasonable risk that some of
> what would be placed there and distributed isn’t actually F/OSS.
And what would be the blowback of something on our server with incorrect
information? Very little. Mostly, we'd just move on. Maybe we delete it.
> I can point you to several example of this. I’m not sure how the incubator
> (or the board) would feel about that risk, so that would be something we
> would be need to consider further. Also
Welp. Then I will pose that question, rather than this endless
pontificating about "risk".
> while Jane and John may be fine with that, a lot of companies that use
> Apache releases may not be.
>
I already acknowledged that. Many people could use software regardless of
its licensing. The license typically only matters in *redistribution*
scenarios. Things like the AGPL affect *usage*, but that is very, very
atypical. I'd think 99% of downstream could use our software, even with
gummed-up licensing.
> > You're conflating *learning* with *releases*. These can be handled
> separately.
>
> How exactly?
You're saying that releases are the control point to learning. I say just
let the releases go.
You want to teach? Then you can use the releases like "that wasn't good.
next time: do A and B". Over time, releases will get fixed. But the IPMC
should not have to manage the releases.
Cheers,
-g
Re: [DISCUSS] IPMC votes on releases
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I see no problem with using our infrastructure to distribute F/OSS
> materials. Why would the Foundation want to be against that? If it is
> labeled properly, then ... roll with it.
It often isn’t labelled properly. There’s a reasonable risk that some of what would be placed there and distributed isn’t actually F/OSS. I can point you to several example of this. I’m not sure how the incubator (or the board) would feel about that risk, so that would be something we would be need to consider further. Also while Jane and John may be fine with that, a lot of companies that use Apache releases may not be.
> You're conflating *learning* with *releases*. These can be handled separately.
How exactly? I’m well aware of the pedagogical (and in particular the andragogical) implications here. I can expand on that or point you to relevant research if you want.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] IPMC votes on releases
Posted by Greg Stein <gs...@gmail.com>.
On Sat, Aug 10, 2019 at 5:29 PM Justin Mclean <ju...@classsoftware.com>
wrote:
> Hi,
>
> I wrote: (dunno why Justin keeps trimming sources for his quotes...)
> > Option (F): stop calling them official ASF releases, which means PMC
> votes
> > are not required.
>
> In that case voting would not be required and they wouldn’t have to follow
> ASF policy.
Right.
> If they are not official releases then we probably can’t release or
> distribute them on ASF infrastructure.
I see no problem with using our infrastructure to distribute F/OSS
materials. Why would the Foundation want to be against that? If it is
labeled properly, then ... roll with it. We distribute a *ton* of stuff
that wasn't produced by the ASF. We incorporate that stuff into a larger
work, but it isn't "ours". Yet we put it onto our servers.
Clearly, these bits and bobs and blobs *are* intended to be F/OSS. Maybe
somebody thinks a LICENSE file isn't correct, so maybe ACME Inc. can't use
it ... but John and Jane and Joe certainly want to, and *can*. Isn't that
our goal?
We do allow connivance binaries but they still have to follow ASF policy
> and have to be made from the source of an official release. In this
> scenario how do podlings learn what is required to make official releases?
>
You're conflating *learning* with *releases*. These can be handled
separately.
Cheers,
-g
not-Infra
Re: [DISCUSS] IPMC votes on releases
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Option (F): stop calling them official ASF releases, which means PMC votes
> are not required.
In that case voting would not be required and they wouldn’t have to follow ASF policy. If they are not official releases then we probably can’t release or distribute them on ASF infrastructure. We do allow connivance binaries but they still have to follow ASF policy and have to be made from the source of an official release. In this scenario how do podlings learn what is required to make official releases?
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] IPMC votes on releases
Posted by Greg Stein <gs...@gmail.com>.
Option (F): stop calling them official ASF releases, which means PMC votes
are not required.
On Fri, Aug 9, 2019 at 12:04 AM Justin Mclean <ju...@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
>
>