On Fri, Apr 25, 2014 at 10:55 AM, 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)
coho does that > 2 - We have only compatibly licensed dependencies (and appropriate NOTICE > lines) This is what a platform maintainer should watch out for. It's fixed on Android now. > 3 - Code is made up of commits by individuals that have signed the > ICLA (or that are trivial commits) This we do well at. > 4 - Archives are properly signed & hashed > 5 - Contents of archives match sha1 of what's in the repo > This works fine as well. > > 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 > Well, there's a reason we do cadence. Of course, Apache seems to despise cadence and the release early, release often thing. That being said, we really just do a quick, broad review instead of an in-depth review. > For us, I think it depends on the tools / plugin / platform, but in > general we try to keep master release-worthy at all times, and so > don't need to do much other than ensure the continuous build is green. So, yeah, personal branches are awesome for this. Every new feature should live in a personal branch until they get merged in. That's basically my thoughts on this so far.
