On Tue, 27 Oct 2015, Martin Graesslin wrote:
On Tuesday, October 27, 2015 6:25:42 AM CET Eric Hameleers wrote:
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.
do you have ideas how this could work? Do you know of any existing
(web)applications to keep track of it? If there is some it should be
relatively easy to set it up - "just" some git hooks for commits on the stable
branch.
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.
Ok, thank's for the info. So in that case given the schedule I outlined I
expect you would go with 5.5.2 or 5.5.3 and skip the previous ones?
Cheers
Martin
Hi Martin,
Indeed I would aim to skip at least the .0 releases and perhaps even
the .1 releases.
Cheers, Eric
--
Eric Hameleers <al...@slackware.com>
Home: http://alien.slackbook.org/blog/
_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
