Re: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates
Hi, > Yes, we should start recommending your approach. I think the IPMC need to decide as a whole on that first. Perhaps call a vote? > I am actually for this as normal course and instituting the “pTLP” as the new > normal as it is actually makes the PPMC more like a TLP from the start. And perhaps keep this seperate from above. One idea did occur to me and that is one solution may not fit all podlings and actually give podlings some choice of what system they want to use when entering the incubator. I also think it needs to be made very clear that some of the alternative suggestions, while sound appealing (e.g. no IPMC votes mean we can get releases out faster), may in some cases result in: a) Podlings taking a lot longer to graduate b) Issues being found where trying to graduate causing disappointment and delays c) Mentors need to put in more effort especially when to come to steps pre-graduation, at a time when not all of them may be as active d) The IPMC may need to do more work at graduation time to check that everything is in order. Now this might only be the case for the small number of codlings that run into trouble, and for the majority it’s fine no matter what system is used. Also I’ll note a -1 vote on a release shouldn't be a big deal (it’s not a veto), but a -1 vote on a graduations would be a much bigger issue. Hopefully this wouldn’t happen and it should be obvious in the discussion about the graduation that more needs to be done, but podlings are going to be be keen to graduate and may overlook some advice at this point. > (1) If a podling gets the 3 +1 binding votes from their mentors and/or IPMC > members on their dev list then they can release and use a [DISCUSS] thread to > solicit improvements for the next release rather than have a “useless” second > round of voting on general@ I can point to many many case where the second round voting has been far from useless. > (3) If “Unofficial” Apache Releases are allowed on the normal podling Apache > Distribution Channels then this [DISCUSS] thread can be used until the > podling is ready for an “Official” Apache Release. As I understand it this > needs approval from Infrastructure. And probably legal. i.e. Would the currently legal shield still apply and is the current disclaimer adequate? Would it have an impact of the cost of that insurance? Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates
Hi Myrle, Yes, we should start recommending your approach. I am actually for this as normal course and instituting the “pTLP” as the new normal as it is actually makes the PPMC more like a TLP from the start. Given our current interpretation of rules that An Official Apache Release requires 3 +1 IPMC Votes: (1) If a podling gets the 3 +1 binding votes from their mentors and/or IPMC members on their dev list then they can release and use a [DISCUSS] thread to solicit improvements for the next release rather than have a “useless” second round of voting on general@ (2) If a podling is making an non-Apache Release as they are transitioning to Apache they can use this mechanism to solicit reviews about how close they are to being able to produce an Official Apache Release. (3) If “Unofficial” Apache Releases are allowed on the normal podling Apache Distribution Channels then this [DISCUSS] thread can be used until the podling is ready for an “Official” Apache Release. As I understand it this needs approval from Infrastructure. Allowing this approach brings podlings more quickly into Apache Releases, but has disadvantages like yet another distinction that may be hard to explain. (4) “pTLP” with some lower number of IPMC votes become the approved podling model for producing “Official” Apache Releases. If this is the model then the IPMC would make the 3 +1 IPMC Vote on a podling's most recent releases a clear graduation requirement. Regards, Dave > On Mar 6, 2019, at 8:15 AM, Myrle Krantz wrote: > > Hey all, > > I've only heard positive feedback on this proposal. It doesn't solve all > our problems, but it would provide a path around some of the bureaucracy. > > Would the other mentors be willing to bring this suggestion to their > podlings? Especially the "young" ones who still need releases outside of > the ASF? > > Best Regards, > Myrle > > On Tue, Feb 26, 2019 at 8:50 AM Myrle Krantz wrote: > >> Motivation: >> >> Some podlings want or need feedback on their releases before they are >> ready to make official Apache releases. They want to discuss releases that >> are not yet ready for a VOTE, or that they are not sure they are ready for >> a vote. They may wish to make an early release outside of the foundation, >> but still test the ASF waters. They prefer to "fail early, fail often and >> fail forward". [1] >> >> >> Proposal: >> >> Podlings should be able to request feedback by starting a "[DISCUSS]" >> thread instead of a "[VOTE]" thread. Discussion should give podlings >> feedback on what they would need to do to bring their release in line with >> the requirements for graduation to TLP. Podlings will be responsible for >> capturing feedback that they accept in work items for their project. >> Feedback provided in a discussion thread will not block a non-ASF release. >> >> Asking for feedback using this mechanism is not obligatory, but rather a >> service that the incubator offers. >> >> >> Arguments for this proposal: >> >> * It's a very small change which may make it easier to implement than some >> of the "throw it all away and start over" proposals circulating, but... >> * It doesn't prevent us from making other larger changes. >> * It's not a rule. It's an offering of an additional service + an >> incremental reduction in stringency of the incubator. >> * It captures some of the value in what we are doing now while increasing >> the degrees of freedom provided to podlings. >> * It is consistent with our values of transparency, collaboration, >> community, pragmatism, meritocracy, and charity. >> >> Best Regards, >> Myrle >> >> 1.) >> https://www.goodreads.com/work/quotes/614412-failing-forward-turning-mistakes-into-stepping-stones-for-success >> - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates
Hey all, I've only heard positive feedback on this proposal. It doesn't solve all our problems, but it would provide a path around some of the bureaucracy. Would the other mentors be willing to bring this suggestion to their podlings? Especially the "young" ones who still need releases outside of the ASF? Best Regards, Myrle On Tue, Feb 26, 2019 at 8:50 AM Myrle Krantz wrote: > Motivation: > > Some podlings want or need feedback on their releases before they are > ready to make official Apache releases. They want to discuss releases that > are not yet ready for a VOTE, or that they are not sure they are ready for > a vote. They may wish to make an early release outside of the foundation, > but still test the ASF waters. They prefer to "fail early, fail often and > fail forward". [1] > > > Proposal: > > Podlings should be able to request feedback by starting a "[DISCUSS]" > thread instead of a "[VOTE]" thread. Discussion should give podlings > feedback on what they would need to do to bring their release in line with > the requirements for graduation to TLP. Podlings will be responsible for > capturing feedback that they accept in work items for their project. > Feedback provided in a discussion thread will not block a non-ASF release. > > Asking for feedback using this mechanism is not obligatory, but rather a > service that the incubator offers. > > > Arguments for this proposal: > > * It's a very small change which may make it easier to implement than some > of the "throw it all away and start over" proposals circulating, but... > * It doesn't prevent us from making other larger changes. > * It's not a rule. It's an offering of an additional service + an > incremental reduction in stringency of the incubator. > * It captures some of the value in what we are doing now while increasing > the degrees of freedom provided to podlings. > * It is consistent with our values of transparency, collaboration, > community, pragmatism, meritocracy, and charity. > > Best Regards, > Myrle > > 1.) > https://www.goodreads.com/work/quotes/614412-failing-forward-turning-mistakes-into-stepping-stones-for-success >
Re: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates
Hey Justin, On Wed, Feb 27, 2019 at 8:33 AM Justin Mclean wrote: > How do we make podling aware they can do this? Obvious people who follow > this list may know, and we can ask mentors to pass it on to their podling > lists, on document on the website and perhaps mention it in Dave’s welcome > package idea. But would that be enough? > Important question! Aren't podlings still required to subscribe to general@incubator? I don't know how the rest of the world figures these things out, but I mostly followed the examples I saw here. So we need to get a few podlings doing this to create visibility. We could do some combination of: * notify all the dev lists for all the podlings * notify just those podlings still doing releases outside of the ASF (which you have helpfully identified) * ask mentors to suggest it to their podlings when a release is imminent and the mentor thinks its a good candidate for this approach. * if a podling approaches you for feedback, ask if you can do so on the general@incubator list. * document it (probably the most obligatory and least effective item on the list. ; o) I'd also like to read Mick's feedback: Do you think replacing release voting with release discussing at podling request as I've suggested would be an improvement? If so, do you have ideas for ways to communicate this to podlings? Best, Myrle
Re: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates
I would consider it a mentor responsibility, just like any other advise on the way towards graduation. There could be explicit mention in the maturity assessment / checklist. -- sent from mobile On Tue, Feb 26, 2019, 11:33 PM Justin Mclean wrote: > Hi, > > > But my proposal to move towards offering early feedback on > > releases works with or without this change. > > +1 > > How do we make podling aware they can do this? Obvious people who follow > this list may know, and we can ask mentors to pass it on to their podling > lists, on document on the website and perhaps mention it in Dave’s welcome > package idea. But would that be enough? > > Thanks, > Justin > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates
Hi, > But my proposal to move towards offering early feedback on > releases works with or without this change. +1 How do we make podling aware they can do this? Obvious people who follow this list may know, and we can ask mentors to pass it on to their podling lists, on document on the website and perhaps mention it in Dave’s welcome package idea. But would that be enough? Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates
Dave, On Tue, Feb 26, 2019 at 10:30 PM Dave Fisher wrote: > The IPMC could consider some changes to the Incubator rules. (As proposed > mostly by Roy on private lists.) > > Allow the VOTE thread to be only on the dev@ list with 0 or 1 mentor vote > required. As long as the DISCLAIMER exists then the pooling release is good. > I think the idea is worth discussing (and I'm still deciding how I feel about it). But my proposal to move towards offering early feedback on releases works with or without this change. For this reason, I suggest you start a separate thread to discuss this proposal. Best, Myrle (Note: since Roy is making his arguments on a private list, you'll have to depend on your own words. If Roy doesn't wish to engage on the public list, we need to respect that.)
Re: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates
+1 I think this proposal could help a lot with how feedback is perceived by podlings! On Mon, Feb 25, 2019 at 11:51 PM Myrle Krantz wrote: > Some podlings want or need feedback on their releases before they are ready > to make official Apache releases. They want to discuss releases that are > not yet ready for a VOTE, or that they are not sure they are ready for a > vote. When such a review is actively requested by the podling, it sets up a dynamic where the recipient can more easily accept and act on the feedback they receive, without losing face. Contrast that with the present, where feedback on releases most often arrives at the time of a release VOTE, where it can be interpreted as punitive. Naturally, we believe that this feedback is essential and a valuable contribution to the podling. So we should set ourselves up to increase the likelihood that it will be perceived that way! Now, it may be the case that a podling doesn't avail itself of the opportunity to request a pre-release review. But so long as they knew about that the service was available, even though they might feel resentful they can only complain so loudly. I read elsethread that some podlings already pro-actively seek out review, which speaks well of such podlings and their Mentors. But I submit while that these conscientious, well-informed podlings will also benefit from system better designed to be constructive and positive, they are not the ones most likely to become disgruntled or even end up in crisis. The linchpin of this proposal is reliable outreach to those podlings who would not seek out this service on their own. If such a podling is not informed, and then later runs into trouble, we will have missed an valuable opportunity. Therefore, I'd suggest that an email to the dev list on this subject ought to be on a mentoring checklist. > Arguments for this proposal: > > * It's a very small change which may make it easier to implement than some > of the "throw it all away and start over" proposals circulating, but... > * It doesn't prevent us from making other larger changes. +1 > * It's not a rule. It's an offering of an additional service + an > incremental reduction in stringency of the incubator. +1, and I'd add that it corrects how the Incubator should see itself -- instead of an enforcer, as a provider of services to podlings. > * It captures some of the value in what we are doing now while increasing > the degrees of freedom provided to podlings. > * It is consistent with our values of transparency, collaboration, >community, pragmatism, meritocracy, and charity. +1, well said! Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates
Hi, > Allow the VOTE thread to be only on the dev@ list with 0 or 1 mentor vote > required. As long as the DISCLAIMER exists then the pooling release is good. > > Once completed the podling sends the vote thread to general@ with [REVIEW] > (or [DISCUSS]). This allows the IPMC to review and comment on how close the > release is to being a fully proper Apache Release. The podling can more > easily take smaller increments while continuing development as they did > before Incubation as well as how they will do it once they graduate. > > Graduation requirements don’t change. > > Thoughts? I think there are some issues with this and not sure how they all can be addressed: - The level of IPMC reviews of releases is likely to go down. Are mentors going to do something at the same level of effort (vote on releases) if it’s optional (review releases)? Similarly with non IPMC members. - With reduced attentions It’s more likely that issues go unnoticed in releases (until graduation time). - Visible progress may be harder for the IPMC to see. - It's possible that more releases will be needed to be done before they are are in line with ASF releases and some podlings will take longer to graduate. - If it does take longer to graduate it likely that some podlings will have less mentor attention towards the end. - Moving "getting it right" just before graduation could cause a couple of issues: a) Things are not fixed until the last minute. It’s just human nature if it doesn’t need to be done right away it's often put off. In that case can the IPMC tell that a podling is ready to graduate? a) Issues are found by the IPMC when a project has asked to graduate and they may be rejected and worse case go through several cycles of trying to graduate. b) Mentors may not be around as much at this time too help. - it's not known if the current DISCLAIMER is enough to cover us (we can ask legal) - It's not know if INFRA will allow distribution of artefacts with serious issues in large numbers on ASF infrastructure (we can ask) If we do do this, rather than change all podlings over to this method, it may be best to do this an experiment (small reversible steps) and see if some podlings would like to try things way and see how it goes. I assume Zipkin may be willing to be one of those. The only issue being the length of the experiment, it will be a few years before we know the outcome. Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates
The IPMC could consider some changes to the Incubator rules. (As proposed mostly by Roy on private lists.) Allow the VOTE thread to be only on the dev@ list with 0 or 1 mentor vote required. As long as the DISCLAIMER exists then the pooling release is good. Once completed the podling sends the vote thread to general@ with [REVIEW] (or [DISCUSS]). This allows the IPMC to review and comment on how close the release is to being a fully proper Apache Release. The podling can more easily take smaller increments while continuing development as they did before Incubation as well as how they will do it once they graduate. Graduation requirements don’t change. Thoughts? Regards, Dave > On Feb 26, 2019, at 12:46 PM, Julian Hyde wrote: > > This change would be useful. > > As a release manager of a podling, the most disheartening thing is latency. > The usual practice is a 72 hour PPMC release vote, followed by a 72 hour IPMC > vote, one of which will cross a weekend, so a negative vote on the last day > of the IPMC vote adds at least a week to the process. A negative vote (or > comment) on day 1 or 2 of the PPMC vote is much less disruptive. > > I encourage reviewers to review a release candidate, and vote, as early as > possible in the 72 hour voting period. I also encourage them to review and > vote even if there have been -1 votes, because they might find other issues > that the previous reviewer(s) missed. Because these practices speed the > process along, and even if the first RC fails, get to a good second RC as > soon as possible. > > Myrle’s proposal to use a [DISCUSS] thread encourages these practices: people > won’t be as tempted to wait for 71 hours before chiming in, and people will > tend to continue to review even after they have seen some negative reviews. > > Julian > > >> On Feb 25, 2019, at 11:50 PM, Myrle Krantz wrote: >> >> Motivation: >> >> Some podlings want or need feedback on their releases before they are ready >> to make official Apache releases. They want to discuss releases that are >> not yet ready for a VOTE, or that they are not sure they are ready for a >> vote. They may wish to make an early release outside of the foundation, >> but still test the ASF waters. They prefer to "fail early, fail often and >> fail forward". [1] >> >> >> Proposal: >> >> Podlings should be able to request feedback by starting a "[DISCUSS]" >> thread instead of a "[VOTE]" thread. Discussion should give podlings >> feedback on what they would need to do to bring their release in line with >> the requirements for graduation to TLP. Podlings will be responsible for >> capturing feedback that they accept in work items for their project. >> Feedback provided in a discussion thread will not block a non-ASF release. >> >> Asking for feedback using this mechanism is not obligatory, but rather a >> service that the incubator offers. >> >> >> Arguments for this proposal: >> >> * It's a very small change which may make it easier to implement than some >> of the "throw it all away and start over" proposals circulating, but... >> * It doesn't prevent us from making other larger changes. >> * It's not a rule. It's an offering of an additional service + an >> incremental reduction in stringency of the incubator. >> * It captures some of the value in what we are doing now while increasing >> the degrees of freedom provided to podlings. >> * It is consistent with our values of transparency, collaboration, >> community, pragmatism, meritocracy, and charity. >> >> Best Regards, >> Myrle >> >> 1.) >> https://www.goodreads.com/work/quotes/614412-failing-forward-turning-mistakes-into-stepping-stones-for-success > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates
Hi, Nice idea. JFYI - This already happens, just not in a formal way, as I often get emails to check podlings releases before they bring them to the IPMC. > I encourage reviewers to review a release candidate, and vote, as early as > possible in the 72 hour voting period. I also encourage them to review and > vote even if there have been -1 votes, because they might find other issues > that the previous reviewer(s) missed. Because these practices speed the > process along, and even if the first RC fails, get to a good second RC as > soon as possible. As we all are volunteers here, and for instance my $dayjob(s) doesn’t involve this, it can be hard to find the time, especially with other things going on. I also tend to hold off voting on podlings I've voted on before and know are good and wait until enough mentors have voted on those. Unless we removed the requirement of an IPMC and replace it with somethings else (and there have been suggested on other lists) I cannot see this part of it improving without more involvement from mentors or the IPMC in voting on releases. Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates
This change would be useful. As a release manager of a podling, the most disheartening thing is latency. The usual practice is a 72 hour PPMC release vote, followed by a 72 hour IPMC vote, one of which will cross a weekend, so a negative vote on the last day of the IPMC vote adds at least a week to the process. A negative vote (or comment) on day 1 or 2 of the PPMC vote is much less disruptive. I encourage reviewers to review a release candidate, and vote, as early as possible in the 72 hour voting period. I also encourage them to review and vote even if there have been -1 votes, because they might find other issues that the previous reviewer(s) missed. Because these practices speed the process along, and even if the first RC fails, get to a good second RC as soon as possible. Myrle’s proposal to use a [DISCUSS] thread encourages these practices: people won’t be as tempted to wait for 71 hours before chiming in, and people will tend to continue to review even after they have seen some negative reviews. Julian > On Feb 25, 2019, at 11:50 PM, Myrle Krantz wrote: > > Motivation: > > Some podlings want or need feedback on their releases before they are ready > to make official Apache releases. They want to discuss releases that are > not yet ready for a VOTE, or that they are not sure they are ready for a > vote. They may wish to make an early release outside of the foundation, > but still test the ASF waters. They prefer to "fail early, fail often and > fail forward". [1] > > > Proposal: > > Podlings should be able to request feedback by starting a "[DISCUSS]" > thread instead of a "[VOTE]" thread. Discussion should give podlings > feedback on what they would need to do to bring their release in line with > the requirements for graduation to TLP. Podlings will be responsible for > capturing feedback that they accept in work items for their project. > Feedback provided in a discussion thread will not block a non-ASF release. > > Asking for feedback using this mechanism is not obligatory, but rather a > service that the incubator offers. > > > Arguments for this proposal: > > * It's a very small change which may make it easier to implement than some > of the "throw it all away and start over" proposals circulating, but... > * It doesn't prevent us from making other larger changes. > * It's not a rule. It's an offering of an additional service + an > incremental reduction in stringency of the incubator. > * It captures some of the value in what we are doing now while increasing > the degrees of freedom provided to podlings. > * It is consistent with our values of transparency, collaboration, > community, pragmatism, meritocracy, and charity. > > Best Regards, > Myrle > > 1.) > https://www.goodreads.com/work/quotes/614412-failing-forward-turning-mistakes-into-stepping-stones-for-success - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
