cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject What should it mean to +1 a release
Date Fri, 25 Apr 2014 17:55:03 GMT
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

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.


Most of 1-5 can be automated, so I think that's worth doing (e.g. run
coho audit-license-headers as a part of the continuous build, e.g. add
a test that x-refs commit authors with the ICLA page, make "coho
verify-archive" also check archive contents)

So, thoughts on all of this?

I can sign up to convert it into a markdown doc within coho, but would
love assistance with the rest.

Mime
View raw message