More Plasma bug fix releases

[tetris4 at openmailbox.org]

On 27-10-2015 13:51, Martin Graesslin wrote:
> Hi distribution maintainers,
> 
> I was thinking about the problem of how we can get bug fixes quicker to 
> our
> user. With a three month release cycle a one-month bug fix cycle sounds 
> too
> long to me.
> 
> So I thought we should make bug fix releases faster and more often. In 
> 5.4 we
> already went for this partially by having the first bug fix earlier. I 
> wanted
> to know how much work this would mean for our distributions. If we ship 
> out
> way more bug fix releases, would you be able to work with it? Would it 
> block
> you? Would you have to skip releases? Or is it just pressing a button 
> to run
> automatic scripts which upload your packages?
> 
> What had I been thinking about? I was thinking about a Fibonacci based 
> release
> schedule. This gives us quick bug fix releases directly after the 
> release with
> slowly larger intervals. Of course it would mean tag and release 
> happens on
> same day.
> 
> So a hypothetical release schedule for Plasma 5.5 could look like:
> * 2015-12-08: 5.5.0
> * 2015-12-15: 5.5.1
> * 2015-12-22: 5.5.2
> * 2016-01-05: 5.5.3
> * 2016-01-26: 5.5.4
> (* 2016-03-01: 5.5.5)
> 
> Opinions?
> 
> Cheers
> Martin
> 
> _______________________________________________
> release-team mailing list
> release-team at kde.org
> https://mail.kde.org/mailman/listinfo/release-team


Hi everyone,

At first glance the proposed release schedule by Martin seems very 
dense, but Chakra should be able to keep up as the Plasma 5 builds do 
not take that long.

The effort and automation required for each Plasma build actually 
depends on the changes that are implemented. For a straightforward build 
we usually only change the version, but when for example new 
dependencies are introduced for new releases, a bit of manual effort is 
required to identify them and include them in our scripts.

What will happen to quick bugfix releases? Like when we have 5.5.1.1  
for some packages when a critical bug is found very soon after the 
release. With releases being so close in the hypothetical scheme this 
might not be needed.

What I think would really help to decide on how to proceed would be to 
take into account the related statistics to better understand how much 
of a problem this is. The number of plasma packages that actually change 
between releases could be identified, as well as how many of these 
changes are really significant ones that need to roll out to users asap. 
If it's not too much trouble, we could for example track the severity of 
the bugs that close for each release, or request from developers to 
point out new commits that they find very important in each release.

The issue comes down to how many distributions can cope with this. If in 
the end most distros end up skipping releases, this release schedule 
doesn't make much meaning.

Regards,
Neofytos Kolokotronis (tetris4 from Chakra),
-long time lurker, happy to be commenting for the first time here-