incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <>
Subject Re: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates
Date Tue, 26 Feb 2019 20:46:54 GMT
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.


> 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.)

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message