Am 2015-10-28 13:34, schrieb Maximiliano Curia:
On 27/10/15 13:51, Martin Graesslin wrote:
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.
Fair enough.
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?
We can keep up with bug fixes, in most cases the bugs will affect our
users
anyway and having the bug fixes released would reduce the time spent
dealing
with bugs, but it would be a waste of time and resources to package
things
that only contain a version bump.
understood. Maybe we can do some scripting to only create tarballs if
there were changes. Jonathan?
So my suggestion would be to publish a 5.5 version and use the dot
releases to
publish bug fixes without a fixed schedule.
Sorry I don't understand what you mean with that. Do you want a new bug
fix release for each commit to stable branch? That certainly wouldn't
scale.
The next discussion would be what should be considered a bug fix to
trigger a
release, as much as I like to have l10n support, the automatic: l10n
daemon
script commit hardly qualify.
While l10n might not seem to be that important to you, it might be the
difference between an unusable system and a useable system. So let's not
start downplaying the importance of translations ;-)
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.
Agreed on the release and tag on the same day. Can it be enforced that
all the
tests need to pass to consider the part for the release
Please start a dedicated discussion for this point.
Also, if possible, could you use signed tags for the releases? (on the
Debian
side of things we are considering using the upstream signed git tags as
a
replacement of tarballs and signatures/sums)
Please also start a dedicated discussion for this point.
Cheers
Martin
_______________________________________________
release-team mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/release-team
