Open Stack

On Thu, 14 Dec 2017, Julien Danjou wrote:

> However, has anyone tried to understand the reasons why it is hard to
> impossible to do anything useful in a cycle, other than "it is too
> short"?

This gets to the root my concern with this proposal and this thread.
I think the idea deserves plenty of consideration, but my initial
reaction has been that it is symptomatic care to ease the impact of
problems, rather than a cure for whatever the disease might be.

Frequently, the outcome that happens when band-aiding symptoms is
that there are a lot of unintended (and unexpected) consequences
that introduce more problems which require more band-aids, and so
on.

For example: if we go to a longer cycle, if some projects choose to
use intermediate or milestone-based releases, while others do not,
how do we manage upgrade (grenade) testing? What complexities will
that introduce?

Is there an opportunity here to decouple consumption of releases
from their creation? This is already the case. Most distributions
and deployments are months if not years behind master. The frequency
at which master is blessed as a release™ doesn't necessarily have to
be coupled with that.

If the core problem we're trying to solve for here is to not
discourage part time contribution, let's get to the root causes of
that. The cycle being too short seems unlikely as a _root_ cause.
Six months is a long time.

If there are multiple problems that we're trying to solve for, let's
be clear about what they are. This thread suggests that "too many
events" is a problem, but that's only associated with cycle length
because we choose for it to be, not because it has to be.

-- 
Chris Dent                      (⊙＿⊙')         https://anticdent.org/
freenode: cdent                                         tw: @anticdent