This would get us into a pretty sweet world. One question: Between [DISCUSS] and [RELEASE] how do we make sure nothing slips in? Should DISCUSS include branching/tagging? Pointing at a CI result? Trust nothing changes?
-Michal On Fri, Apr 25, 2014 at 2:55 PM, Brian LeRoux <[email protected]> wrote: > :+1: > > > On Fri, Apr 25, 2014 at 11:45 AM, Jesse <[email protected]> wrote: > > > +1 to this also. > > > > Starting a new thread on the subject of automating #3 > > > > > > > > > > @purplecabbage > > risingj.com > > > > > > On Fri, Apr 25, 2014 at 11:35 AM, Joe Bowser <[email protected]> wrote: > > > > > +1 to this! > > > > > > On Fri, Apr 25, 2014 at 11:29 AM, Ian Clelland <[email protected] > > > > > wrote: > > > > 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 > > > > > >
