More Plasma bug fix releases
tetris4 at openmailbox.org
tetris4 at openmailbox.org
Tue Oct 27 21:03:43 UTC 2015
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
> user. With a three month release cycle a one-month bug fix cycle sounds
> 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
> to know how much work this would mean for our distributions. If we ship
> way more bug fix releases, would you be able to work with it? Would it
> 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
> 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)
> release-team mailing list
> release-team at kde.org
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 184.108.40.206
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.
Neofytos Kolokotronis (tetris4 from Chakra),
-long time lurker, happy to be commenting for the first time here-
More information about the release-team