Fwd: KDE Frameworks Release Cycle

Martin Gräßlin mgraesslin at kde.org
Tue May 20 11:28:29 UTC 2014


On Tuesday 20 May 2014 07:19:59 Scott Kitterman wrote:
> On May 20, 2014 4:19:26 AM EDT, Jos Poortvliet <jospoortvliet at gmail.com> 
wrote:
> >On Tuesday 20 May 2014 19:07:41 Ben Cooksley wrote:
> >> On Tue, May 20, 2014 at 6:04 PM, Kevin Ottens <ervin at kde.org> wrote:
> ><snip>
> >
> >> > Now, I think we'll have to agree to disagree on something. You
> >
> >believe
> >
> >> > there's some rule written in stone somewhere which will make the
> >> > "everyone will pile up backports only" the new status quo forever,
> >
> >I say
> >
> >> > let's try and find out.
> >> 
> >> In the meantime, everyone but the developers will suffer.
> >
> >Yes, and saying no to every proposal won't change that.
> >
> >I believe that the only advantage of the current situation (slow
> >release
> >cycle with a period of 'bugfixes' that go untested) seems to be that it
> >is a
> >known evil: we're lying about them being stable bugfix releases but the
> 
> They are almost completely bugfix. Every now and then something slips
> through, but those are mistakes.
> 
> We (packagers) know exactly how much testing gets done upstream, so we test
> them before releasing to our users.

I already mentioned this once in this thread: such testing has to be done 
upstream. It is a waste of all distro's time if every distro tests 
independently the same things, and a bad experience if you miss to test 
something due to lack of knowledge [1].

I'm quite convince that there is a middle ground which will help the 
developers and the packagers way. We only have to accept that there will be 
changes and start to move a little bit. I see here so much possibilities to 
improve the workflows, but so far all I saw from distro side is "change is 
bad". Let's try a little bit harder to improve the situation :-)

Cheers
Martin

[1] We had pretty bad regressions in KWin once which no distro spotted. From 0 
to 10 with 10 being the worst imaginable bug, it scored an 11.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/release-team/attachments/20140520/d5140189/attachment.sig>


More information about the release-team mailing list