On Wednesday, April 30, 2014 14:39:31 Martin Gräßlin wrote: > On Wednesday 30 April 2014 08:24:43 Scott Kitterman wrote: > > On Wednesday, April 30, 2014 11:35:54 Àlex Fiestas wrote: > > > On Tuesday 29 April 2014 19:23:07 Scott Kitterman wrote: > > > > For non-rolling distros, at some point you have to stop and release. A > > > > mix > > > > of new features and bug fixes aren't going to be allowed in. > > > > > > > > We (Kubuntu) have been delivering KDE SC point releases as > > > > post-release > > > > updates to our users for most (maybe all) KDE4 releases. That's over > > > > with > > > > KF5. > > > > > > > > We'll, I guess, have to settle for cherry picking fixes and doing our > > > > best. > > > > > > You might not know this but most developers don't do proper testing in > > > the > > > stable branches because the cost of having master and stable > > > environments > > > and doing testing in both branches for each fix is too much, we simply > > > don't have the manpower for that. > > > > > > History has shown this maaaany times, we have done point releases that > > > were > > > horrible quality-wise because nobody was testing them. The stable > > > branches > > > have virtually no users. > > > > > > I have been told by you (at UDS) and by many others packagers that our > > > point releases suck, that we introduce huge regressions etc. The above > > > paragraph explains the reason. > > > > > > We have to be realistic here, upstream does NOT have the manpower to > > > maintain more than one release. > > > > > > So, I honestly think that if we work together you can do a better work > > > cherry- picking than we can. Also we should develop tools to make your > > > life > > > easier. > > > > We test the point releases before we ship them to end users. Sometimes we > > find regressions. It happens. I'm pretty sure I didn't say the suck. > > I've invested a lot of hours of my free time both getting approval to ship > > them post release and packaging them as well. I wouldn't have done that > > if > > I thought they sucked. > > > > I'm well aware of the amount of testing the stable branches get. That's > > why we do the testing we do before we ship them. I can't recall the last > > time we had end user complaints of a regression after a stable update has > > been released to end users. > > > > I think the best tool to make our life easier would be maintenance > > branches. If you only want to have one every 3 - 6 KF5 releases, fine. > > I know that this is a change from how it is right now: but wouldn't it be > better if those who are interested do these branches? Let's face it whatever > we do upstream cannot suite all of our downstreams at the same time. > > And please remember: this is only about frameworks, not about the > applications or the workspace.
I know. I think it's unlikely that people who don't know the code as well will do a better job of cherrypicking into a maintenance branch. Despite the lack of testing, my impression is that KDE developers do a pretty good job of deciding what should go into maintenance branches. Remember that a lot of people working in the distros (myself included) aren't Qt/KDE programmers, we're packagers. I can integrate and test stuff really well. I know I'm not qualified to consider all the aspects of risk versus benefit of a change in upstream code to see if it's appropriate for a maintenance update or not. KF5 developers are going to do it the way they see best. I'm not trying to tell anyone how they have to do things. I do, however, want to make it clear what the likely consequences of the current plan are. Scott K _______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team