open the floodgates...

open the floodgates...

[Sage Weil]

and release the (pull requests with code destined for) kraken!

One question: we moved from a 'next' branch to 'jewel' branch for the 
development period to represent the 'frozen' bugfix branch before each 
development checkpoint release.  Should we

1) Use a 'kraken' branch, just like we did with jewel.  After each dev 
release, merge in the next lump of new stuff from master.

2) Go back to a 'next' branch, like we did pre-jewel.

3) Give up on the delayed dev checkpoint release thing we've been doing 
(where we send bug fixes to next or kraken for 2 weeks before release) and 
just release regular checkpoints of master (as 11.0.z).

4) Stop doing development checkpoint releases entirely and let testers 
pull automated builds from gitbuilder or jenkins.

Thoughts?
sage

Re: open the floodgates...

[Nathan Cutler]

On 04/21/2016 09:03 PM, Sage Weil wrote:
> and release the (pull requests with code destined for) kraken!
>
> One question: we moved from a 'next' branch to 'jewel' branch for the
> development period to represent the 'frozen' bugfix branch before each
> development checkpoint release.  Should we
>
> 1) Use a 'kraken' branch, just like we did with jewel.  After each dev
> release, merge in the next lump of new stuff from master.\

I've become accustomed to this, so it seems natural to me. Subjectively, +1

> 2) Go back to a 'next' branch, like we did pre-jewel.

No, thanks.

> 3) Give up on the delayed dev checkpoint release thing we've been doing
> (where we send bug fixes to next or kraken for 2 weeks before release) and
> just release regular checkpoints of master (as 11.0.z).

Though this delay introduces some complexity, we have it documented and 
it serves a good purpose: i.e. making the dev checkpoint releases more 
stable.

> 4) Stop doing development checkpoint releases entirely and let testers
> pull automated builds from gitbuilder or jenkins.

Psychologically, the "imprimatur" of a checkpoint release is reassuring. 
Perhaps more importantly, the granularity of point releases has 
information value. You ask someone what version they are running - with 
dev checkpoint releases they say "10.1.2". Without them, they would say 
"4a2a6f72640d6b74a3bbd92798bb913ed380dcd4".

-- 
Nathan Cutler
Software Engineer Distributed Storage
SUSE LINUX, s.r.o.
Tel.: +420 284 084 037

Re: open the floodgates...

[Alfredo Deza]

On Sat, Apr 23, 2016 at 4:21 AM, Nathan Cutler <ncutler@suse.cz> wrote:
> On 04/21/2016 09:03 PM, Sage Weil wrote:
>>
>> and release the (pull requests with code destined for) kraken!
>>
>> One question: we moved from a 'next' branch to 'jewel' branch for the
>> development period to represent the 'frozen' bugfix branch before each
>> development checkpoint release.  Should we
>>
>> 1) Use a 'kraken' branch, just like we did with jewel.  After each dev
>> release, merge in the next lump of new stuff from master.\
>
>
> I've become accustomed to this, so it seems natural to me. Subjectively, +1
>
>> 2) Go back to a 'next' branch, like we did pre-jewel.
>
>
> No, thanks.
>
>> 3) Give up on the delayed dev checkpoint release thing we've been doing
>> (where we send bug fixes to next or kraken for 2 weeks before release) and
>> just release regular checkpoints of master (as 11.0.z).
>
>
> Though this delay introduces some complexity, we have it documented and it
> serves a good purpose: i.e. making the dev checkpoint releases more stable.
>
>> 4) Stop doing development checkpoint releases entirely and let testers
>> pull automated builds from gitbuilder or jenkins.
>
>
> Psychologically, the "imprimatur" of a checkpoint release is reassuring.
> Perhaps more importantly, the granularity of point releases has information
> value. You ask someone what version they are running - with dev checkpoint
> releases they say "10.1.2". Without them, they would say
> "4a2a6f72640d6b74a3bbd92798bb913ed380dcd4".

What about a middle ground: keep the checkpoint releases but automated
like the gitbuilders: the releases would be incremental and
have a release cadence that could be nightly/weekly/every-other-day.

This would also play nicely with #3 were we could already be cutting
dev releases for 11.0.z

Keeping releases coming from the actual release-named branch (e.g.
'jewel') would help the current release process that bases the model
around that
idea (we have never cut a release from a 'next' or 'master' branch).

>
> --
> Nathan Cutler
> Software Engineer Distributed Storage
> SUSE LINUX, s.r.o.
> Tel.: +420 284 084 037
>
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html