On Wednesday, July 10, 2013 06:54:06 PM Àlex Fiestas wrote: > On Wednesday 10 July 2013 18:26:55 you wrote: > > On Wednesday 10 of July 2013 18:08:04 Àlex Fiestas wrote: > > > On Wednesday 10 July 2013 13:22:20 Sune Vuorela wrote: > > > > On 2013-07-09, Sune Vuorela <nos...@vuorela.dk> wrote: > > > > > So. first one. > > > > > > > > Second one > > > > > > > > Release frequency. > > > > > > > > We have a giant quality problem. Distros won't ship a .0 release to > > > > real > > > > users (as opposed to testers/power users) and wait until there has > > > > been > > > > a couple of bug fix releases. Until we ensure that our .0 releases are > > > > usable I don't see how we can cut down on that. > > > > > > > > Some distros release in a 6 month cycle. Others in a 8. and ones even > > > > in > > > > longer cycles. Going for anything shorter than 6 months will ensure > > > > that > > > > distros are going to skip releases. why work with releases that they > > > > aren't going to ship to users anyways? > > > > > > Not by distributions working that way I guess. > > > > > > Part of the reasons why I want this release schedule is exactly for > > > these > > > distros. Let me explain. > > > > > > Right now distributions pick the release they see fit and make a distro > > > with it. It might be .0, .2 or .5. > > > > > > If a distribution in their right decide to pick a .5 release wile a .0 > > > is > > > already out there (this already happened), what is happening here is > > > that > > > a > > > HUGE release with a LOT of changes won't even get to the users of that > > > distribution at least for another distribution cycle. This usually > > > happens > > > with distributions that have a release cycle of 9 months. > > > > The Linux kernel itself maintain old branches with big number of point > > releases. See 3.0.85, 3.2.48, 3.4.52, done by kernel developers. > > Done by the kernel developers interested on those. > > My proposal is to make the parties interested on this, actually do this. > > > > [...] > > > > > > > And as it currently is, we need the .4 and .5 releases. > > > > > > and .6 and .7 and .8 and .9, we could have a 4.0.200, there is always > > > need > > > of bugfixing releases, question is how many of these point releases are > > > pending of upstream KDE and not downstream distros. > > > > > > To make it clear, I WANT to have .4 and .5 releases, just not made by > > > upstream developers. > > > > Uhm... are you sure this will work? It can work for paid contributors, but > > not for unpaid ones. Moreover, this means that it's fine if users don't > > receive > > > the last version, which was one of your goals stated above: > I can't fight with distros, and I don't want to fight with them. If distros > need .5 .6 and .200 so be it, just they will have to do them themselves (and > I hope we can make the process smooth so they can actually do it). > > As has been said in this thread, almost no KDE developer is using the stable > branch, blindly backporting has shown to be dangerous and has created many > issues in the past so we are not the right people to make these point > releases.
I think distros can help with getting more testing and even provide good feedback on if a point release is baked. I don't think we should be looking in git and deciding what should be backported or not. I think the developers of the code should do that. Scott K
