incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Myrle Krantz <my...@apache.org>
Subject Re: the case of the maven wrapper
Date Mon, 18 Feb 2019 12:39:42 GMT
On Thu, Feb 14, 2019 at 7:05 AM Mick Semb Wever <mck@apache.org> wrote:

> One of the tings I've noticed is that the vetos on a podling's first
> release can be a bit harsh.
>
<snip>

> On releases I would rather see such vetos replaced with comments that are
> feedback, while still obvious that they are an issue that is expected to be
> fixed by the next release (and before graduation). I think this would be
> warmer feedback, and permit a more incremental approach to getting to the
> standard of release required for graduation.


I have to disagree here. I’ve been watching Justin vote on releases for
*years* now. No one is more prolific (not even by half). And he always
gives detailed reasons for his vote. He’s also very clear about what issues
he sees as blockers and what issues aren’t blockers, but that he’d like to
see resolved before graduation. The overarching principle is clear: if it
could place users, contributors, or the ASF in jeopardy we veto. Justin is
very good at finding these.  This is the reason that, even though vetos
don’t technically block the release, when Justin states a -1, others will
often withdraw a +1.

And yes: that’s frustrating. No amount of warm verbiage added to the veto
will change the fact that it’s frustrating.  Would you rather we accept the
legal jeopardy?

Justin is not always right about a given detail.  No one is.  That may be
the case in this specific instance.  But what I'm responding to is a
general statement about the way our release vetting process.  I do not
believe we are too harsh.

I’d also note: we are all doing this on his own *unpaid* time. While our
communications should be clear and empathetic there are still limits as to
how much time we can spend on our emails (and how many words others will
read). At some point the reader will need to take responsibility for their
own reactions.

Best Regards,
Myrle

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message