What should it mean to +1 a release

[Andrew Grieve <ag...@chromium.org>]

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.

Re: What should it mean to +1 a release

[Michal Mocny <mm...@chromium.org>]

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 <b...@brian.io> wrote:

> :+1:
>
>
> On Fri, Apr 25, 2014 at 11:45 AM, Jesse <pu...@gmail.com> 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 <bo...@gmail.com> wrote:
> >
> > > +1 to this!
> > >
> > > On Fri, Apr 25, 2014 at 11:29 AM, Ian Clelland <iclelland@chromium.org
> >
> > > wrote:
> > > > On Fri, Apr 25, 2014 at 1:55 PM, Andrew Grieve <agrieve@chromium.org
> >
> > > 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
> > >
> >
>

Re: What should it mean to +1 a release

[Brian LeRoux <b...@brian.io>]

:+1:


On Fri, Apr 25, 2014 at 11:45 AM, Jesse <pu...@gmail.com> 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 <bo...@gmail.com> wrote:
>
> > +1 to this!
> >
> > On Fri, Apr 25, 2014 at 11:29 AM, Ian Clelland <ic...@chromium.org>
> > wrote:
> > > On Fri, Apr 25, 2014 at 1:55 PM, Andrew Grieve <ag...@chromium.org>
> > 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
> >
>

Re: What should it mean to +1 a release

[Jesse <pu...@gmail.com>]

+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 <bo...@gmail.com> wrote:

> +1 to this!
>
> On Fri, Apr 25, 2014 at 11:29 AM, Ian Clelland <ic...@chromium.org>
> wrote:
> > On Fri, Apr 25, 2014 at 1:55 PM, Andrew Grieve <ag...@chromium.org>
> 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
>

Re: What should it mean to +1 a release

[Joe Bowser <bo...@gmail.com>]

+1 to this!

On Fri, Apr 25, 2014 at 11:29 AM, Ian Clelland <ic...@chromium.org> wrote:
> On Fri, Apr 25, 2014 at 1:55 PM, Andrew Grieve <ag...@chromium.org> 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

Re: What should it mean to +1 a release

[Ian Clelland <ic...@chromium.org>]

On Fri, Apr 25, 2014 at 1:55 PM, Andrew Grieve <ag...@chromium.org> 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

Re: What should it mean to +1 a release

[Andrew Grieve <ag...@chromium.org>]

Should have mentioned - I did do that :). I added a link to it in the vote
email template.


On Fri, May 2, 2014 at 10:09 PM, Carlos Santana <cs...@gmail.com>wrote:

> Andrew,
>  Should we add a link to this document from the other
> *-release-process.md[1], maybe near the section "Start VOTE Thread"?
>
> [1]:
>
> https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md#start-vote-thread
>
> https://github.com/apache/cordova-coho/blob/master/docs/cadence-release-process.md#start-vote-thread
>
> https://github.com/apache/cordova-coho/blob/master/docs/tools-release-process.md#start-vote-thread
>
>
>
> On Fri, May 2, 2014 at 7:53 AM, Andrew Grieve <ag...@chromium.org>
> wrote:
>
> > Only if you run the command.
> >
> >
> > On Thu, May 1, 2014 at 1:26 PM, Joe Bowser <bo...@gmail.com> wrote:
> >
> > > Doesn't coho audit every time we cut a release?
> > >
> > > On Thu, May 1, 2014 at 10:17 AM, Andrew Grieve <ag...@chromium.org>
> > > wrote:
> > > > Drafted this up here:
> > > >
> > >
> >
> https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
> > > >
> > > > Feel free to make changes directly, or to propose changes via pull
> > > requests.
> > > >
> > > >
> > > > On Fri, Apr 25, 2014 at 5:15 PM, James Jong <wj...@gmail.com>
> > > wrote:
> > > >
> > > >> I went to Marvin’s talk on the release process at ApacheCon and
> > several
> > > of
> > > >> the Cordova committers spoke with him afterwards.  He was very
> > > >> knowledgeable and willing to help.  Any help in smoothing out the
> > > release
> > > >> process while limiting the overhead would be greatly appreciated
> > Marvin.
> > > >> -James Jong
> > > >>
> > > >> On Apr 25, 2014, at 3:25 PM, Marvin Humphrey <
> marvin@rectangular.com>
> > > >> wrote:
> > > >>
> > > >> > On Fri, Apr 25, 2014 at 10:55 AM, Andrew Grieve <
> > agrieve@chromium.org
> > > >
> > > >> 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.
> > > >> >
> > > >> > I'd like to help with this.  ASF release policy is an area of
> > > expertise
> > > >> for
> > > >> > me, and I look forward in particular to suggesting mechanisms
> which
> > > >> reduce
> > > >> > overhead while keeping Cordova and the ASF in sync.
> > > >> >
> > > >> > Marvin Humphrey
> > > >>
> > > >>
> > >
> >
>
>
>
> --
> Carlos Santana
> <cs...@gmail.com>
>

Re: What should it mean to +1 a release

[Carlos Santana <cs...@gmail.com>]

Andrew,
 Should we add a link to this document from the other
*-release-process.md[1], maybe near the section "Start VOTE Thread"?

[1]:
https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md#start-vote-thread
https://github.com/apache/cordova-coho/blob/master/docs/cadence-release-process.md#start-vote-thread
https://github.com/apache/cordova-coho/blob/master/docs/tools-release-process.md#start-vote-thread



On Fri, May 2, 2014 at 7:53 AM, Andrew Grieve <ag...@chromium.org> wrote:

> Only if you run the command.
>
>
> On Thu, May 1, 2014 at 1:26 PM, Joe Bowser <bo...@gmail.com> wrote:
>
> > Doesn't coho audit every time we cut a release?
> >
> > On Thu, May 1, 2014 at 10:17 AM, Andrew Grieve <ag...@chromium.org>
> > wrote:
> > > Drafted this up here:
> > >
> >
> https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
> > >
> > > Feel free to make changes directly, or to propose changes via pull
> > requests.
> > >
> > >
> > > On Fri, Apr 25, 2014 at 5:15 PM, James Jong <wj...@gmail.com>
> > wrote:
> > >
> > >> I went to Marvin’s talk on the release process at ApacheCon and
> several
> > of
> > >> the Cordova committers spoke with him afterwards.  He was very
> > >> knowledgeable and willing to help.  Any help in smoothing out the
> > release
> > >> process while limiting the overhead would be greatly appreciated
> Marvin.
> > >> -James Jong
> > >>
> > >> On Apr 25, 2014, at 3:25 PM, Marvin Humphrey <ma...@rectangular.com>
> > >> wrote:
> > >>
> > >> > On Fri, Apr 25, 2014 at 10:55 AM, Andrew Grieve <
> agrieve@chromium.org
> > >
> > >> 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.
> > >> >
> > >> > I'd like to help with this.  ASF release policy is an area of
> > expertise
> > >> for
> > >> > me, and I look forward in particular to suggesting mechanisms which
> > >> reduce
> > >> > overhead while keeping Cordova and the ASF in sync.
> > >> >
> > >> > Marvin Humphrey
> > >>
> > >>
> >
>



-- 
Carlos Santana
<cs...@gmail.com>

Re: What should it mean to +1 a release

[Andrew Grieve <ag...@chromium.org>]

Only if you run the command.


On Thu, May 1, 2014 at 1:26 PM, Joe Bowser <bo...@gmail.com> wrote:

> Doesn't coho audit every time we cut a release?
>
> On Thu, May 1, 2014 at 10:17 AM, Andrew Grieve <ag...@chromium.org>
> wrote:
> > Drafted this up here:
> >
> https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
> >
> > Feel free to make changes directly, or to propose changes via pull
> requests.
> >
> >
> > On Fri, Apr 25, 2014 at 5:15 PM, James Jong <wj...@gmail.com>
> wrote:
> >
> >> I went to Marvin’s talk on the release process at ApacheCon and several
> of
> >> the Cordova committers spoke with him afterwards.  He was very
> >> knowledgeable and willing to help.  Any help in smoothing out the
> release
> >> process while limiting the overhead would be greatly appreciated Marvin.
> >> -James Jong
> >>
> >> On Apr 25, 2014, at 3:25 PM, Marvin Humphrey <ma...@rectangular.com>
> >> wrote:
> >>
> >> > On Fri, Apr 25, 2014 at 10:55 AM, Andrew Grieve <agrieve@chromium.org
> >
> >> 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.
> >> >
> >> > I'd like to help with this.  ASF release policy is an area of
> expertise
> >> for
> >> > me, and I look forward in particular to suggesting mechanisms which
> >> reduce
> >> > overhead while keeping Cordova and the ASF in sync.
> >> >
> >> > Marvin Humphrey
> >>
> >>
>

Re: What should it mean to +1 a release

[Joe Bowser <bo...@gmail.com>]

Doesn't coho audit every time we cut a release?

On Thu, May 1, 2014 at 10:17 AM, Andrew Grieve <ag...@chromium.org> wrote:
> Drafted this up here:
> https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
>
> Feel free to make changes directly, or to propose changes via pull requests.
>
>
> On Fri, Apr 25, 2014 at 5:15 PM, James Jong <wj...@gmail.com> wrote:
>
>> I went to Marvin’s talk on the release process at ApacheCon and several of
>> the Cordova committers spoke with him afterwards.  He was very
>> knowledgeable and willing to help.  Any help in smoothing out the release
>> process while limiting the overhead would be greatly appreciated Marvin.
>> -James Jong
>>
>> On Apr 25, 2014, at 3:25 PM, Marvin Humphrey <ma...@rectangular.com>
>> wrote:
>>
>> > On Fri, Apr 25, 2014 at 10:55 AM, Andrew Grieve <ag...@chromium.org>
>> 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.
>> >
>> > I'd like to help with this.  ASF release policy is an area of expertise
>> for
>> > me, and I look forward in particular to suggesting mechanisms which
>> reduce
>> > overhead while keeping Cordova and the ASF in sync.
>> >
>> > Marvin Humphrey
>>
>>

Re: What should it mean to +1 a release

[Andrew Grieve <ag...@chromium.org>]

Drafted this up here:
https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md

Feel free to make changes directly, or to propose changes via pull requests.


On Fri, Apr 25, 2014 at 5:15 PM, James Jong <wj...@gmail.com> wrote:

> I went to Marvin’s talk on the release process at ApacheCon and several of
> the Cordova committers spoke with him afterwards.  He was very
> knowledgeable and willing to help.  Any help in smoothing out the release
> process while limiting the overhead would be greatly appreciated Marvin.
> -James Jong
>
> On Apr 25, 2014, at 3:25 PM, Marvin Humphrey <ma...@rectangular.com>
> wrote:
>
> > On Fri, Apr 25, 2014 at 10:55 AM, Andrew Grieve <ag...@chromium.org>
> 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.
> >
> > I'd like to help with this.  ASF release policy is an area of expertise
> for
> > me, and I look forward in particular to suggesting mechanisms which
> reduce
> > overhead while keeping Cordova and the ASF in sync.
> >
> > Marvin Humphrey
>
>

Re: What should it mean to +1 a release

[James Jong <wj...@gmail.com>]

I went to Marvin’s talk on the release process at ApacheCon and several of the Cordova committers spoke with him afterwards.  He was very knowledgeable and willing to help.  Any help in smoothing out the release process while limiting the overhead would be greatly appreciated Marvin.
-James Jong

On Apr 25, 2014, at 3:25 PM, Marvin Humphrey <ma...@rectangular.com> wrote:

> On Fri, Apr 25, 2014 at 10:55 AM, Andrew Grieve <ag...@chromium.org> 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.
> 
> I'd like to help with this.  ASF release policy is an area of expertise for
> me, and I look forward in particular to suggesting mechanisms which reduce
> overhead while keeping Cordova and the ASF in sync.
> 
> Marvin Humphrey

Re: What should it mean to +1 a release

[Marvin Humphrey <ma...@rectangular.com>]

On Fri, Apr 25, 2014 at 10:55 AM, Andrew Grieve <ag...@chromium.org> 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.

I'd like to help with this.  ASF release policy is an area of expertise for
me, and I look forward in particular to suggesting mechanisms which reduce
overhead while keeping Cordova and the ASF in sync.

Marvin Humphrey

Re: What should it mean to +1 a release

[Marvin Humphrey <ma...@rectangular.com>]

On Fri, Apr 25, 2014 at 11:34 AM, Joe Bowser <bo...@gmail.com> wrote:
> Well, there's a reason we do cadence.  Of course, Apache seems to
> despise cadence and the release early, release often thing.

There is no Apache policy stopping Cordova from scheduling release votes on a
fixed cadence.  CouchDB does it now -- here's Dave Cottlehuber singing its
praises:

    http://s.apache.org/aV7

    I agree; in the CouchDB community we had a similar experience. Addressing
    it has been positive both for our brand and for our community. It's also
    been a triumph of Apache values of community over code, demonstrating that
    the incubator process, as well as addressing legal concerns via due
    diligence, is also capable of sustaining communities who can survive the
    acrimonious departure of the founder. Moving to a time-driven release has
    helped us enormously.

Marvin Humphrey

Re: What should it mean to +1 a release

[Joe Bowser <bo...@gmail.com>]

On Fri, Apr 25, 2014 at 10:55 AM, Andrew Grieve <ag...@chromium.org> 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.

Re: What should it mean to +1 a release

[Marcel Kinard <cm...@gmail.com>]

On Apr 25, 2014, at 1:55 PM, Andrew Grieve <ag...@chromium.org> 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.

Totally agree. I think there is some variation currently in what we understand it means to "+1 a release". An explicit definition would get us all on the same page.

> 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.

Keeping master consistently release-ready fits both what I heard from the board at ApacheCon, and how we traditionally do things.

> 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)

Yeah, automate everything that is reasonably possible.