cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: What should it mean to +1 a release
Date Fri, 25 Apr 2014 18:35:05 GMT
+1 to this!

On Fri, Apr 25, 2014 at 11:29 AM, Ian Clelland <iclelland@chromium.org> wrote:
> On Fri, Apr 25, 2014 at 1:55 PM, Andrew Grieve <agrieve@chromium.org> wrote:
>
>> Had some discussions about this at ApacheCon, and I think it would be
>> good to formalize this in a release-process doc within coho/docs.
>>
>> The best Apache docs for it is:
>> https://www.apache.org/dev/release-publishing.html
>>
>> When we (or at least, members of the PMC), vote on a release, we
>> (should) be saying that we are confident that:
>> 1 - Our sources are properly licenses (aka, RAT or coho
>> audit-license-headers)
>> 2 - We have only compatibly licensed dependencies (and appropriate NOTICE
>> lines)
>> 3 - Code is made up of commits by individuals that have signed the
>> ICLA (or that are trivial commits)
>> 4 - Archives are properly signed & hashed
>> 5 - Contents of archives match sha1 of what's in the repo
>>
>>
>> Note that this list doesn't include anything about the *quality* of
>> the code. This subject was more grey, and is more up to each project
>> to figure out.
>> - Some projects go as far as reviewing every commit that has occurred
>> since the previous commit
>>
>
> I was thinking about this, in light of the recent plugins release, and I
> think that it makes sense for quality concerns to be aired in the [DISCUSS]
> thread that should be happen before the [VOTE] thread. That is a better
> place for anyone to step up and say "I think there are quality problems
> with component X; let's not release that just yet".
>
> That saves the release manager a lot of time packaging up a release that's
> going to be downvoted anyway, and then the [VOTE] thread can be more
> efficient.
>
> This isn't saying, of course, that people *can't* downvote a release for
> any reason whatsoever, including quality concerns, but I think it would
> make surprises like that much less likely.
>
> Ian

Mime
View raw message