On Fri, Apr 25, 2014 at 1:55 PM, Andrew Grieve <[email protected]> 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
