Build Master: Scheduling

[ponce]

On Thursday, 14 November 2013 at 00:37:38 UTC, Tyro[17] wrote:
> 
> Bugfix releases (2.064.1)
>     Based on the previous major release or bugfix; contains 
> only bugfixes and perhaps documentation corrections.
>
>
> Your thoughts and concerns please.

Do you happen to work with me? We have two dozens of such 
releases branch :) And customers still tend to prefer the 
slightly bleeding edge ones.

While this effectively _does_ work in creating more stable 
releases, I think that it puts all the burden on the developers 
in a way that is difficult to ignore.

Most of the time backporting is little work, but sometimes you 
need to redo a fix you already did, for a branch which only exist 
to be phased out a bit later, in a codebase slightly different in 
ways nobody can tell anymore. Sometimes it's even very hard to 
backport a fix, but if you don't do it how to tell which branch 
has which bugs?

Coupled with being forced to backport every bugfix to every 
branch, this can make a compelling enough reason never to 
contribute.

With a typical bad fix injection rate of ~5%, this also mean 
regressions will crop up in release branches and never be noticed 
since they are not introduced at HEAD level but by the very act 
of backporting.

I'm not sure it can be done in a way that feels right. I prefer 
the N-month release cycle we have, and take as much time and 
Release Candidates as needed.