On Tue, 27 Oct 2015, 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
I like the idea of getting more visibility for bugfixes that will give
the enduser a better Plasma experience. Ideal for me would be a patch
tracker (not the same as a bug tracker) where intermediate patches are
made available that are scheduled for inclusion in the next release.
That allows me as a package builder to assimilate those patches if I
think they can not wait until the next release.
I do much more than maintaining the Plasma 5 package set for
Slackware. So my users get an update once a month, where I incorporate
the latest Frameworks, Plasma and Applications. It is just not humanly
possible to do more than that. Internediate patch releases will be
ignored by me, that is why I hinted at a patch tracker instead.
Cheers, Eric
--
Eric Hameleers <[email protected]>
Home: http://alien.slackbook.org/blog/
_______________________________________________
release-team mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/release-team
