[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-release-team
Subject:    Re: More Plasma bug fix releases
From:       Martin_Gräßlin <mgraesslin () kde ! org>
Date:       2015-10-28 13:49:34
Message-ID: 6f3411076896d4a3975919ed3854fa25 () mail ! martin-graesslin ! com
[Download RAW message or body]

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
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

[prev in list] [next in list] [prev in thread] [next in thread]