DISCUSS: Establishing a release cadence

[Daniel Ruggeri <DR...@primary.net>]

Hi, all;

   I know we've chatted about this somewhat in the past so I wanted to
kick off a formal topic to see if we can establish consensus for a
release cadence of httpd. As a strawman proposal, I'd like to suggest
that we...

 * Ensure stable branches are always in a releasable state (I believe
this to currently be the case, right?)

 * Codify and automate the creation/handling of the release bits in a
CI/CD job plan

 * Plan to release whatever is in stable branches every quarter via the job

 * Plan to "release" unstable/trunk bundles monthly

 * Support the ability to run the job ad-hoc for emergency fixes


As a swag, all of the above is to make the work of the RM relatively
light so more folks from the community can/will participate. There have
been a few cases where features or fixes have sat in 2.4 without release
because Jim or Bill just hadn't kicked off the process and committed
their free time to doing it. The other thought is to help provide some
degree of regularity our community (users and devs alike) can come to
expect as well as do whatever we can to easily get experimental trunk
bits in peoples' hands for testing.


Thoughts?


-- 
Daniel Ruggeri

Re: DISCUSS: Establishing a release cadence

[Mark Blackman <ma...@exonetric.com>]

> On 2 Nov 2017, at 10:51, Daniel Ruggeri <DR...@primary.net> wrote:
> 
> Hi, all;
> 
>    I know we've chatted about this somewhat in the past so I wanted to
> kick off a formal topic to see if we can establish consensus for a
> release cadence of httpd. As a strawman proposal, I'd like to suggest
> that we...
> 
>  * Ensure stable branches are always in a releasable state (I believe
> this to currently be the case, right?)
> 
>  * Codify and automate the creation/handling of the release bits in a
> CI/CD job plan
> 
>  * Plan to release whatever is in stable branches every quarter via the job
> 
>  * Plan to "release" unstable/trunk bundles monthly
> 
>  * Support the ability to run the job ad-hoc for emergency fixes
> 
> 
> As a swag, all of the above is to make the work of the RM relatively
> light so more folks from the community can/will participate. There have
> been a few cases where features or fixes have sat in 2.4 without release
> because Jim or Bill just hadn't kicked off the process and committed
> their free time to doing it. The other thought is to help provide some
> degree of regularity our community (users and devs alike) can come to
> expect as well as do whatever we can to easily get experimental trunk
> bits in peoples' hands for testing.
> 
> 
> Thoughts?

Broadly reasonable, I can volunteer some online hardware if it helps. You might be shorter of people than hardware though.

- Mark