Fwd: KDE Frameworks Release Cycle

[Scott Kitterman]

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