Re: [BuildStream] Buildstream releasing model

[Agustín Benito Bethencourt <agustin benito codethink co uk>]

Hi,

On Monday, 30 July 2018 16:51:34 CEST Paul Sherwood via Buildstream-list 
wrote:
> Hi folks,
> as discussed on IRC today (from [1] onwards) I (and others) think that
> the BuildStream releasing model is confusing for new users and would
> like to suggest that we change it now, rather than later.
>
> IIUC understand it Tristan chose the current model because it is
> commonly used in GNOME projects, but I don't think that's a good
> justification.

Many projects that does not control the deployment environment are rolling 
when it comes to development and freeze when it comes to stable. 

Distros are already on or moving to this model, not just upstream projects 
like GNOME or KDE (KDE LTS versions).

I agree though that "everybody else" is doing it is not a good 
justification. Let's go back to the reason why they are doing it: distros 
and tools projects do not control the deployment of their software.

They came to this model as a good enough compromise between:
* Being as agile as possible in their development process
* Follow devops principles in the delivery phase
* Their customers business needs, the deployers (distributors in the case 
of upstream projects). Deployers do not want to assume the risk involved in 
rollbacks.

So although I was not involved in the decision of choosing master+ 
stabilization phase, at this point I think it is a good one.

We can only think about being more aggressive in the release model when:
* We have a more robust delivery process in place, given the change rate is 
increasing since I joined.
* Our users are willing to take the risks involved in rollbacks which, in 
corporate environments, specially mission critical ones, it is unlikely. It 
is more likely in R&D environments. Definitely those who will use 
BuildStream in the cloud will only look at master if they already have 
short lead times, high throughput and short recovery rates.

I see the release model/process as a tool that serves a purpose. The 
current model, with limitations, is designed to serve both, those who are 
willing to accept the risks of roll-backs and those who don't. Obviously 
that comes at a cost, which is backporting and maintaining stable branches. 

Who are we creating BuildStream for?

A different story comes when you control the deployment. In such case, when 
your development and delivery process is solid, you can decide to take the 
risks involved in rollbacks. As you know, there are several tactics to 
reduce the risk.There are even products to do it.

Best Regards

-- 
Agustín Benito Bethencourt
Principal Consultant
Codethink Ltd
We respect your privacy.   See https://www.codethink.co.uk/privacy.html