cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <>
Subject Re: What should it mean to +1 a release
Date Fri, 25 Apr 2014 18:34:39 GMT
On Fri, Apr 25, 2014 at 10:55 AM, Andrew Grieve <> 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:
> 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.

View raw message