On Tuesday, May 20, 2014 13:28:29 Martin Gräßlin wrote: > On Tuesday 20 May 2014 07:19:59 Scott Kitterman wrote: > > On May 20, 2014 4:19:26 AM EDT, Jos Poortvliet <jospoortvl...@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 <er...@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 :-)
I'm open to discussing change, but so far the change is "You're on your own, get over it". Not a lot to discuss in that. Scott K _______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team