Fwd: KDE Frameworks Release Cycle
kde at kitterman.com
Wed Apr 30 13:12:14 UTC 2014
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 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.
More information about the release-team