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 <my...@apache.org> 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
