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
[email protected]
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-
_______________________________________________
release-team mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/release-team
