incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ant elder <ant.el...@gmail.com>
Subject Re: Release Verification Checklist
Date Mon, 09 Dec 2013 11:30:02 GMT
On Mon, Dec 9, 2013 at 11:04 AM, Bertrand Delacretaz
<bdelacretaz@apache.org> wrote:
> Hi,
>
> On Mon, Dec 9, 2013 at 11:34 AM, ant elder <ant.elder@gmail.com> wrote:
>> ...2) Podlings should normally graduate after the first release  (and we
>> should more proactively do that) not stay to do more...
>
> I wouldn't set this as a goal. It's nice when it happens, but as you
> say the goal is for a podling to be generally healthy and to have
> understood the Apache invariants before graduating. It's not the
> number of releases.
>

Yes sometimes podlings may need to stay longer, but think about it -
if a podling does all thats required including the first release, and
then graduates, from then on they get binding votes on everything
including their releases. If something means they can't graduate yet
why does that mean they shouldn't get binding votes on subsequent
releases? Surely that should only happen if they are staying because
their first release was a disaster. The other reasons to keep them
here are separate from the competence at doing releases so saying they
don't get the binding votes on subsequent releases is just punishment
that they haven't yet resolved the unrelated issue.



>> ...If we could find a way to have Incubator PMC members accept a lower
>> bar for doing podling releases it would make a massive improvement to
>> everyones experience of the Incubator....
>
> Define "lower bar". Do you see any of the review items
> http://incubator.apache.org/guides/release_manifest.txt as optional?
>

Probably all of those could be optional or fixed next time. I've done
releases with invalid signatures in the past and there is some
automated thing in the ASF distribution area that sends you an email
about it and you just have to resign the artifact. If the podling
choose to do a release knowing some tests fail thats up to them, i can
think of a number of releases happened here missing the DISCLAIMER
file and they were told just fix it next time, etc for the rest of the
items on the list. We've even had Incubator releases including GPL
dependencies in the past. The point is i think that podlings learn
about the requirements but that doesn't mean we must block releases or
make people jump through hoops to do that learning.

   ...ant

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message