Release logistics

[Sean Busbey <bu...@apache.org>]

Hi folks!

We'll be getting to our first set of release candidates shortly, and
there are a couple of open questions we need to get some consensus on.


1) Release Staging

As a part of making release candidates, a release manager needs to
update the version number from in-progress to whatever the release
will be  (i.e. 0.1.0-SNAPSHOT to 0.1.0).

I suggest we take on a common strategy that I've seen work well before:

* create a staging branch (i.e. 0.1.0-staging)
* add a commit with the to-be-voted-on version number
* generate an RC
* if RC feedback results in more changes to the master branch, cherry
pick as needed
* (loop on generating RCs)
* When a VOTE passes, create a release tag for the commit hash that
passed and delete the branch

Current restrictions on deleting refs aside, this gives us a place
away from the main branch to make janitorial changes, a well-defined
place to start any future maintenance branches, and it keeps our
branches limited to those that are active right now.

2) Release timelines and cadence

ASF policy requires that release votes be atleast 72 hours, everything
else is up to us. As we gain adoption we're likely to be in the
critical path for other development shops, so I'd like us to take an
aggressive stance on getting changes out into releases.

Presuming there have been changes since the prior release, how about
we aim for a schedule of calling a release vote every Friday ~noon PT
that closes at Monday ~noon PT?

-- 
Sean

Re: Release logistics

[Chris Nauroth <cn...@hortonworks.com>]

I see.  If we expect API instability, then a "0." release line is a
helpful indicator.

--Chris Nauroth




On 12/10/15, 10:53 AM, "Allen Wittenauer" <aw...@altiscale.com> wrote:

>
>> On Dec 10, 2015, at 10:46 AM, Chris Nauroth <cn...@hortonworks.com>
>>wrote:
>> 1. How would people feel about calling it 1.0.0?  Is there something
>> specific we're hedging on by calling it a "0." release?
>
>	For me, I know I¹m expecting there to still be quite a bit of movement
>in the plug-in API.  For example, I know I¹ve got a big change coming in
>how the help usage is output.  There¹s also a few ASF-specific bits that
>need some cleanup with regards to non-ASF folks really getting the most
>out of test-patch.
>
>
>> 2. If I'm reading this correctly, you're suggesting weekly releases if
>> there are code changes.  With only 6 PMC members who have binding votes,
>> it's a lot to ask of a small number of people.  I see a risk of many of
>> these votes fizzling out and expiring without getting enough binding
>> votes.  How would you feel about a longer regular cadence, such as
>> monthly, with the option to invoke additional out-of-band releases as
>> needed for critical fixes?
>
>
>	I think this is a great point.
>
>
>	Thanks!

Re: Release logistics

[Allen Wittenauer <aw...@altiscale.com>]

> On Dec 10, 2015, at 10:46 AM, Chris Nauroth <cn...@hortonworks.com> wrote:
> 1. How would people feel about calling it 1.0.0?  Is there something
> specific we're hedging on by calling it a "0." release?

	For me, I know I’m expecting there to still be quite a bit of movement in the plug-in API.  For example, I know I’ve got a big change coming in how the help usage is output.  There’s also a few ASF-specific bits that need some cleanup with regards to non-ASF folks really getting the most out of test-patch.  


> 2. If I'm reading this correctly, you're suggesting weekly releases if
> there are code changes.  With only 6 PMC members who have binding votes,
> it's a lot to ask of a small number of people.  I see a risk of many of
> these votes fizzling out and expiring without getting enough binding
> votes.  How would you feel about a longer regular cadence, such as
> monthly, with the option to invoke additional out-of-band releases as
> needed for critical fixes?


	I think this is a great point.


	Thanks!

Re: Release logistics

[Sean Busbey <bu...@apache.org>]

for folks who'd like follow along, YETUS-228.

On Thu, Dec 10, 2015 at 11:22 AM, Chris Nauroth
<cn...@hortonworks.com> wrote:
> I was thinking of it more like my other projects, where I typically do a
> small QA pass over the release, specifically testing several of the new
> patches and regression testing existing features that have a recent
> history of quality problems.  That kind of RC validation typically takes
> me multiple hours to complete.
>
> I'm happy to try the weekly cadence and possibly settle into a shorter
> validation process.  We can tune the process later if we start to see the
> weekly votes fizzle.
>
> +1 overall for the plan.
>
> --Chris Nauroth
>
>
>
>
> On 12/10/15, 10:53 AM, "Sean Busbey" <bu...@apache.org> wrote:
>
>>On Thu, Dec 10, 2015 at 10:46 AM, Chris Nauroth
>><cn...@hortonworks.com> wrote:
>>>
>>> 2. If I'm reading this correctly, you're suggesting weekly releases if
>>> there are code changes.  With only 6 PMC members who have binding votes,
>>> it's a lot to ask of a small number of people.  I see a risk of many of
>>> these votes fizzling out and expiring without getting enough binding
>>> votes.  How would you feel about a longer regular cadence, such as
>>> monthly, with the option to invoke additional out-of-band releases as
>>> needed for critical fixes?
>>>
>>
>>I'm not sure. For most of the projects I'm involved in, I'd agree. But
>>for Yetus we dog food almost everything. At the time of a RC, it seems
>>like the only thing to do is check hashes and signatures on two files.
>>
>>How much time would that be? We won't really know until we start
>>having them, I suppose. If it's ~10 minutes, is that too much?
>>
>

Re: Release logistics

[Allen Wittenauer <aw...@altiscale.com>]

> On Dec 10, 2015, at 5:59 PM, Andrew Purtell <an...@gmail.com> wrote:
> 
> dogfooding. (Although - I dislike that term, can we find another?)


	Scott McNealy always said Sun flies it’s own airplanes.

	(paraphrasing) “Airplanes are more important and harder to make than dog food.  Let our competitors eat their own dog food."

Re: Release logistics

[Andrew Purtell <an...@gmail.com>]

This project is probably better equipped than most to make release candidate validation only a small increment in effort over precommit or nightly tests. As Sean said, dogfooding. (Although - I dislike that term, can we find another?) It should be little more that verifying hashes, signature, notice/license file presence and correctness. Weekly releases could be doable. Certainly I would have time on a weekly basis for that. 

In contrast, yeah, Hadoop or HBase builds... Whenever spinning those for public or private consumption it is an *all day* affair.


> On Dec 10, 2015, at 11:22 AM, Chris Nauroth <cn...@hortonworks.com> wrote:
> 
> I was thinking of it more like my other projects, where I typically do a
> small QA pass over the release, specifically testing several of the new
> patches and regression testing existing features that have a recent
> history of quality problems.  That kind of RC validation typically takes
> me multiple hours to complete.
> 
> I'm happy to try the weekly cadence and possibly settle into a shorter
> validation process.  We can tune the process later if we start to see the
> weekly votes fizzle.
> 
> +1 overall for the plan.
> 
> --Chris Nauroth
> 
> 
> 
> 
>> On 12/10/15, 10:53 AM, "Sean Busbey" <bu...@apache.org> wrote:
>> 
>> On Thu, Dec 10, 2015 at 10:46 AM, Chris Nauroth
>> <cn...@hortonworks.com> wrote:
>>> 
>>> 2. If I'm reading this correctly, you're suggesting weekly releases if
>>> there are code changes.  With only 6 PMC members who have binding votes,
>>> it's a lot to ask of a small number of people.  I see a risk of many of
>>> these votes fizzling out and expiring without getting enough binding
>>> votes.  How would you feel about a longer regular cadence, such as
>>> monthly, with the option to invoke additional out-of-band releases as
>>> needed for critical fixes?
>> 
>> I'm not sure. For most of the projects I'm involved in, I'd agree. But
>> for Yetus we dog food almost everything. At the time of a RC, it seems
>> like the only thing to do is check hashes and signatures on two files.
>> 
>> How much time would that be? We won't really know until we start
>> having them, I suppose. If it's ~10 minutes, is that too much?
> 

Re: Release logistics

[Chris Nauroth <cn...@hortonworks.com>]

I was thinking of it more like my other projects, where I typically do a
small QA pass over the release, specifically testing several of the new
patches and regression testing existing features that have a recent
history of quality problems.  That kind of RC validation typically takes
me multiple hours to complete.

I'm happy to try the weekly cadence and possibly settle into a shorter
validation process.  We can tune the process later if we start to see the
weekly votes fizzle.

+1 overall for the plan.

--Chris Nauroth




On 12/10/15, 10:53 AM, "Sean Busbey" <bu...@apache.org> wrote:

>On Thu, Dec 10, 2015 at 10:46 AM, Chris Nauroth
><cn...@hortonworks.com> wrote:
>>
>> 2. If I'm reading this correctly, you're suggesting weekly releases if
>> there are code changes.  With only 6 PMC members who have binding votes,
>> it's a lot to ask of a small number of people.  I see a risk of many of
>> these votes fizzling out and expiring without getting enough binding
>> votes.  How would you feel about a longer regular cadence, such as
>> monthly, with the option to invoke additional out-of-band releases as
>> needed for critical fixes?
>>
>
>I'm not sure. For most of the projects I'm involved in, I'd agree. But
>for Yetus we dog food almost everything. At the time of a RC, it seems
>like the only thing to do is check hashes and signatures on two files.
>
>How much time would that be? We won't really know until we start
>having them, I suppose. If it's ~10 minutes, is that too much?
>

Re: Release logistics

[Sean Busbey <bu...@apache.org>]

On Thu, Dec 10, 2015 at 10:46 AM, Chris Nauroth
<cn...@hortonworks.com> wrote:
>
> 2. If I'm reading this correctly, you're suggesting weekly releases if
> there are code changes.  With only 6 PMC members who have binding votes,
> it's a lot to ask of a small number of people.  I see a risk of many of
> these votes fizzling out and expiring without getting enough binding
> votes.  How would you feel about a longer regular cadence, such as
> monthly, with the option to invoke additional out-of-band releases as
> needed for critical fixes?
>

I'm not sure. For most of the projects I'm involved in, I'd agree. But
for Yetus we dog food almost everything. At the time of a RC, it seems
like the only thing to do is check hashes and signatures on two files.

How much time would that be? We won't really know until we start
having them, I suppose. If it's ~10 minutes, is that too much?

Re: Release logistics

[Chris Nauroth <cn...@hortonworks.com>]

A few thoughts:

1. How would people feel about calling it 1.0.0?  Is there something
specific we're hedging on by calling it a "0." release?

2. If I'm reading this correctly, you're suggesting weekly releases if
there are code changes.  With only 6 PMC members who have binding votes,
it's a lot to ask of a small number of people.  I see a risk of many of
these votes fizzling out and expiring without getting enough binding
votes.  How would you feel about a longer regular cadence, such as
monthly, with the option to invoke additional out-of-band releases as
needed for critical fixes?

The proposed mechanics of releasing look great to me.  Please feel free to
proceed with trying it.


--Chris Nauroth




On 12/10/15, 10:40 AM, "Allen Wittenauer" <aw...@altiscale.com> wrote:

>While we are discussing this, Sean and I are going to try and run through
>this process over the next 24 hours to see if there are kinks with the
>goal of cutting a real (yes, really!) RC as a potential release.  If
>anyone wants us to hold back, let us know pretty quickly. ;)
>
>Thanks!
>
>
>> On Dec 10, 2015, at 10:29 AM, Sean Busbey <bu...@apache.org> wrote:
>> 
>> Hi folks!
>> 
>> We'll be getting to our first set of release candidates shortly, and
>> there are a couple of open questions we need to get some consensus on.
>> 
>> 
>> 1) Release Staging
>> 
>> As a part of making release candidates, a release manager needs to
>> update the version number from in-progress to whatever the release
>> will be  (i.e. 0.1.0-SNAPSHOT to 0.1.0).
>> 
>> I suggest we take on a common strategy that I've seen work well before:
>> 
>> * create a staging branch (i.e. 0.1.0-staging)
>> * add a commit with the to-be-voted-on version number
>> * generate an RC
>> * if RC feedback results in more changes to the master branch, cherry
>> pick as needed
>> * (loop on generating RCs)
>> * When a VOTE passes, create a release tag for the commit hash that
>> passed and delete the branch
>> 
>> Current restrictions on deleting refs aside, this gives us a place
>> away from the main branch to make janitorial changes, a well-defined
>> place to start any future maintenance branches, and it keeps our
>> branches limited to those that are active right now.
>> 
>> 2) Release timelines and cadence
>> 
>> ASF policy requires that release votes be atleast 72 hours, everything
>> else is up to us. As we gain adoption we're likely to be in the
>> critical path for other development shops, so I'd like us to take an
>> aggressive stance on getting changes out into releases.
>> 
>> Presuming there have been changes since the prior release, how about
>> we aim for a schedule of calling a release vote every Friday ~noon PT
>> that closes at Monday ~noon PT?
>> 
>> -- 
>> Sean
>
>

Re: Release logistics

[Allen Wittenauer <aw...@altiscale.com>]

While we are discussing this, Sean and I are going to try and run through this process over the next 24 hours to see if there are kinks with the goal of cutting a real (yes, really!) RC as a potential release.  If anyone wants us to hold back, let us know pretty quickly. ;)

Thanks!


> On Dec 10, 2015, at 10:29 AM, Sean Busbey <bu...@apache.org> wrote:
> 
> Hi folks!
> 
> We'll be getting to our first set of release candidates shortly, and
> there are a couple of open questions we need to get some consensus on.
> 
> 
> 1) Release Staging
> 
> As a part of making release candidates, a release manager needs to
> update the version number from in-progress to whatever the release
> will be  (i.e. 0.1.0-SNAPSHOT to 0.1.0).
> 
> I suggest we take on a common strategy that I've seen work well before:
> 
> * create a staging branch (i.e. 0.1.0-staging)
> * add a commit with the to-be-voted-on version number
> * generate an RC
> * if RC feedback results in more changes to the master branch, cherry
> pick as needed
> * (loop on generating RCs)
> * When a VOTE passes, create a release tag for the commit hash that
> passed and delete the branch
> 
> Current restrictions on deleting refs aside, this gives us a place
> away from the main branch to make janitorial changes, a well-defined
> place to start any future maintenance branches, and it keeps our
> branches limited to those that are active right now.
> 
> 2) Release timelines and cadence
> 
> ASF policy requires that release votes be atleast 72 hours, everything
> else is up to us. As we gain adoption we're likely to be in the
> critical path for other development shops, so I'd like us to take an
> aggressive stance on getting changes out into releases.
> 
> Presuming there have been changes since the prior release, how about
> we aim for a schedule of calling a release vote every Friday ~noon PT
> that closes at Monday ~noon PT?
> 
> -- 
> Sean