Re: [DISCUSS] IPMC votes on releases
Hi - > On Aug 12, 2019, at 6:41 AM, Matt Sicker 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 revi...@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 > 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" : >> >>On Sun, Aug 11, 2019 at 6:32 AM Justin Mclean < >> jus...@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
Re: [DISCUSS] IPMC votes on releases
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 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" : > > On Sun, Aug 11, 2019 at 6:32 AM Justin Mclean < > jus...@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-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > -- Matt Sicker
Re: [DISCUSS] IPMC votes on releases
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" : On Sun, Aug 11, 2019 at 6:32 AM Justin Mclean 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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] IPMC votes on releases
On Sun, Aug 11, 2019 at 6:32 AM Justin Mclean 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
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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] IPMC votes on releases
On Sat, Aug 10, 2019 at 5:29 PM Justin Mclean 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
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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] IPMC votes on releases
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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] IPMC votes on releases
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 wrote: > Hi, > > One of the incubator pain points is the double voting on releases first by > the podling and then by the IPMC. > > Historically there been a lot of discussion about this and a couple of > proposals to try and change it, but none have been accepted. There have > been proposals on alternative ways to vote and to ask for guidances which > have been accepted, but podlings don’t seem to take these options up. I’m > hoping the recent DISCLAIMER-WIP is one that is used more by podlings, and > go some way to helping podling get releases out, but time will tell. > > When consider what to do about this, please keep this in mind: > 1. Only PMC members can have binding votes on releases (it’s in our > bylaws) so a minimum of 3 IPMC votes are require to make a release. > 2. Podlings are not TLP and don’t have a PMC and PPMC members votes are > not binding on releases. > 3. The IPMC picks up some serious issues in (about 1 in 5) releases by > checking this way. This is mostly, but not always, on the early releases. > > So option (A) would be to get the Bylaws changed and treat podlings as > TLPs. > > Another option (B) is to get all mentors to vote on every release. We’ve > tried this via various means and it seems only a couple of podlings can > manage this. > > One (perhaps not carefully considered) option (C) would be to vote in all > PPMC members as IPMC and make PPMC members IPMC members when projects are > first created rather than incubator committers. If we did this we could > optionally gate graduation on a review of a podlings releases but that may > be unpopular. There have also been complaints in the past that he IPMC is > too large, so increasing the IPMC size this way may also not be popular. > > A variation on (C) let call it option (D) would be to vote in podling > release mangers into the IPMC after they have done a number of releases > along with podling committers that provide good feedback on a number of > release candidates. That way when starting out a podling is likely to need > the IPMC help, but one they have a few releases under their belts they will > have enough IPMC votes without having to reply on mentors or other IPMC > members. It would also encourage more careful voting on releases, If you > just go +1 with giving some detail you’re not going to be voted into the > IPMC. This wouldn't require any bylaws or policy change, we could just go > ahead and do it. It would require the mentors help in identifying good > candidates. > > One further idea I have is (E) is that if a podling does have 3 IPMC votes > on it dev list and are using the DISCLAIMER-WIP disclaimer, they can just > notify the IPMC that they are making a release, the IPMC can review it and > and any issues or feedback found can incorporated into the next release or > before graduation as per [1]. This may mean that there’s a risk that a > release has to be taken down and redone - (see issues that are blockers in > that ticket), but most issues found over the notification it would be > business as usual. > > So IMO options (A) and (C) above seem unlikely to happen, and (B) isn’t > really working, but option (D) combined with (E) along with the recent > DISCLAIMER-WIP I think could would improve the situation. > > Does anyone have any other ideas they care to share? > > Thanks, > Justin > > 1. https://issues.apache.org/jira/projects/LEGAL/issues/LEGAL-469 > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [DISCUSS] IPMC votes on releases
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
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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] IPMC votes on releases
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" : On Sat, 10 Aug 2019 at 12:45, Paul King 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 > 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)
Re: [DISCUSS] IPMC votes on releases
On Sat, 10 Aug 2019 at 12:45, Paul King 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 > wrote: > > > Hi, > > > > One of the incubator pain points is the double voting on releases first by > > the podling and then by the IPMC. > > > > Historically there been a lot of discussion about this and a couple of > > proposals to try and change it, but none have been accepted. There have > > been proposals on alternative ways to vote and to ask for guidances which > > have been accepted, but podlings don’t seem to take these options up. I’m > > hoping the recent DISCLAIMER-WIP is one that is used more by podlings, and > > go some way to helping podling get releases out, but time will tell. > > > > When consider what to do about this, please keep this in mind: > > 1. Only PMC members can have binding votes on releases (it’s in our > > bylaws) so a minimum of 3 IPMC votes are require to make a release. > > 2. Podlings are not TLP and don’t have a PMC and PPMC members votes are > > not binding on releases. > > 3. The IPMC picks up some serious issues in (about 1 in 5) releases by > > checking this way. This is mostly, but not always, on the early releases. > > > > So option (A) would be to get the Bylaws changed and treat podlings as > > TLPs. > > > > Another option (B) is to get all mentors to vote on every release. We’ve > > tried this via various means and it seems only a couple of podlings can > > manage this. > > > > One (perhaps not carefully considered) option (C) would be to vote in all > > PPMC members as IPMC and make PPMC members IPMC members when projects are > > first created rather than incubator committers. If we did this we could > > optionally gate graduation on a review of a podlings releases but that may > > be unpopular. There have also been complaints in the past that he IPMC is > > too large, so increasing the IPMC size this way may also not be popular. > > > > A variation on (C) let call it option (D) would be to vote in podling > > release mangers into the IPMC after they have done a number of releases > > along with podling committers that provide good feedback on a number of > > release candidates. That way when starting out a podling is likely to need > > the IPMC help, but one they have a few releases under their belts they will > > have enough IPMC votes without having to reply on mentors or other IPMC > > members. It would also encourage more careful voting on releases, If you > > just go +1 with giving some detail you’re not going to be voted into the > > IPMC. This wouldn't require any bylaws or policy change, we could just go > > ahead and do it. It would require the mentors help in identifying good > > candidates. > > > > One further idea I have is (E) is that if a podling does have 3 IPMC votes > > on it dev list and are using the DISCLAIMER-WIP disclaimer, they can just > > notify the IPMC that they are making a release, the IPMC can review it and > > and any issues or feedback found can incorporated into the next release or > > before graduation as per [1]. This may mean that there’s a risk that a > > release has to be taken down and redone - (see issues that are blockers in > > that ticket), but most issues found over the notification it would be > > business as usual. > > > > So IMO options (A) and (C) above seem unlikely to happen, and (B) isn’t > > really working, but option (D) combined with (E) along with the recent > > DISCLAIMER-WIP I think could would improve the situation. > > > > Does anyone have any other ideas they care to share? > > > > Thanks, > > Justin > > > > 1. https://issues.apache.org/jira/projects/LEGAL/issues/LEGAL-469 > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail:
Re: [DISCUSS] IPMC votes on releases
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 wrote: > Hi, > > One of the incubator pain points is the double voting on releases first by > the podling and then by the IPMC. > > Historically there been a lot of discussion about this and a couple of > proposals to try and change it, but none have been accepted. There have > been proposals on alternative ways to vote and to ask for guidances which > have been accepted, but podlings don’t seem to take these options up. I’m > hoping the recent DISCLAIMER-WIP is one that is used more by podlings, and > go some way to helping podling get releases out, but time will tell. > > When consider what to do about this, please keep this in mind: > 1. Only PMC members can have binding votes on releases (it’s in our > bylaws) so a minimum of 3 IPMC votes are require to make a release. > 2. Podlings are not TLP and don’t have a PMC and PPMC members votes are > not binding on releases. > 3. The IPMC picks up some serious issues in (about 1 in 5) releases by > checking this way. This is mostly, but not always, on the early releases. > > So option (A) would be to get the Bylaws changed and treat podlings as > TLPs. > > Another option (B) is to get all mentors to vote on every release. We’ve > tried this via various means and it seems only a couple of podlings can > manage this. > > One (perhaps not carefully considered) option (C) would be to vote in all > PPMC members as IPMC and make PPMC members IPMC members when projects are > first created rather than incubator committers. If we did this we could > optionally gate graduation on a review of a podlings releases but that may > be unpopular. There have also been complaints in the past that he IPMC is > too large, so increasing the IPMC size this way may also not be popular. > > A variation on (C) let call it option (D) would be to vote in podling > release mangers into the IPMC after they have done a number of releases > along with podling committers that provide good feedback on a number of > release candidates. That way when starting out a podling is likely to need > the IPMC help, but one they have a few releases under their belts they will > have enough IPMC votes without having to reply on mentors or other IPMC > members. It would also encourage more careful voting on releases, If you > just go +1 with giving some detail you’re not going to be voted into the > IPMC. This wouldn't require any bylaws or policy change, we could just go > ahead and do it. It would require the mentors help in identifying good > candidates. > > One further idea I have is (E) is that if a podling does have 3 IPMC votes > on it dev list and are using the DISCLAIMER-WIP disclaimer, they can just > notify the IPMC that they are making a release, the IPMC can review it and > and any issues or feedback found can incorporated into the next release or > before graduation as per [1]. This may mean that there’s a risk that a > release has to be taken down and redone - (see issues that are blockers in > that ticket), but most issues found over the notification it would be > business as usual. > > So IMO options (A) and (C) above seem unlikely to happen, and (B) isn’t > really working, but option (D) combined with (E) along with the recent > DISCLAIMER-WIP I think could would improve the situation. > > Does anyone have any other ideas they care to share? > > Thanks, > Justin > > 1. https://issues.apache.org/jira/projects/LEGAL/issues/LEGAL-469 > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [DISCUSS] IPMC votes on releases
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 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-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [DISCUSS] IPMC votes on releases
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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] IPMC votes on releases
(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 wrote: > Hi, > > One of the incubator pain points is the double voting on releases first by > the podling and then by the IPMC. > > Historically there been a lot of discussion about this and a couple of > proposals to try and change it, but none have been accepted. There have > been proposals on alternative ways to vote and to ask for guidances which > have been accepted, but podlings don’t seem to take these options up. I’m > hoping the recent DISCLAIMER-WIP is one that is used more by podlings, and > go some way to helping podling get releases out, but time will tell. > > When consider what to do about this, please keep this in mind: > 1. Only PMC members can have binding votes on releases (it’s in our > bylaws) so a minimum of 3 IPMC votes are require to make a release. > 2. Podlings are not TLP and don’t have a PMC and PPMC members votes are > not binding on releases. > 3. The IPMC picks up some serious issues in (about 1 in 5) releases by > checking this way. This is mostly, but not always, on the early releases. > > So option (A) would be to get the Bylaws changed and treat podlings as > TLPs. > > Another option (B) is to get all mentors to vote on every release. We’ve > tried this via various means and it seems only a couple of podlings can > manage this. > > One (perhaps not carefully considered) option (C) would be to vote in all > PPMC members as IPMC and make PPMC members IPMC members when projects are > first created rather than incubator committers. If we did this we could > optionally gate graduation on a review of a podlings releases but that may > be unpopular. There have also been complaints in the past that he IPMC is > too large, so increasing the IPMC size this way may also not be popular. > > A variation on (C) let call it option (D) would be to vote in podling > release mangers into the IPMC after they have done a number of releases > along with podling committers that provide good feedback on a number of > release candidates. That way when starting out a podling is likely to need > the IPMC help, but one they have a few releases under their belts they will > have enough IPMC votes without having to reply on mentors or other IPMC > members. It would also encourage more careful voting on releases, If you > just go +1 with giving some detail you’re not going to be voted into the > IPMC. This wouldn't require any bylaws or policy change, we could just go > ahead and do it. It would require the mentors help in identifying good > candidates. > > One further idea I have is (E) is that if a podling does have 3 IPMC votes > on it dev list and are using the DISCLAIMER-WIP disclaimer, they can just > notify the IPMC that they are making a release, the IPMC can review it and > and any issues or feedback found can incorporated into the next release or > before graduation as per [1]. This may mean that there’s a risk that a > release has to be taken down and redone - (see issues that are blockers in > that ticket), but most issues found over the notification it would be > business as usual. > > So IMO options (A) and (C) above seem unlikely to happen, and (B) isn’t > really working, but option (D) combined with (E) along with the recent > DISCLAIMER-WIP I think could would improve the situation. > > Does anyone have any other ideas they care to share? > > Thanks, > Justin > > 1. https://issues.apache.org/jira/projects/LEGAL/issues/LEGAL-469 > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
