[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: About Testing Freeze and KDE

The Wanderer wrote:
> Bob Proulx wrote:
> > Good!  Then you saw that I did answer your question!  :-)
> > 
> > As I said...  The reason that KDE 4.14.3 isn't in Jessie is because
> > when Jessie froze KDE 4.14.2 was the latest available.  KDE 4.14.3
> > was announced on 2014-Nov-11 several days *after* the freeze on
> > 2014-Nov-05.  That was after the freeze.  At the time of the freeze
> > KDE 4.14.3 *did not exist*.  Asking why 4.14.3 isn't in Jessie is
> > the same question as asking why 4.14.4 isn't in Jessie.  Because
> > 4.14.4 doesn't exist yet.
> No, it isn't the same question, because 4.14.3 does exist now; it just
> didn't when the freeze took place.

Uhm...  But that is the entire point of "freeze"!  What does freeze
mean to you?  Since Jessie is frozen and it was frozen *before* KDE
4.14.3 existed means that KDE 4.14.3 can't have been in it.

I think this is going to become a discussion of the process for
making a release.  That is okay.  But that does seem like a different
topic to me.

> Referring back to the OP, the original question was whether the version
> currently in testing would be updated prior to the release, and whether
> it wouldn't make sense to do so - the latter of which is essentially...

A couple of points.  One is that anyone is free to submit a wishlist
bug in the BTS requesting a newer version be packaged into the
archive.  Those requests happen all of the time.  If there is a newer
version and someone specifically wants it then they are free to submit
a bug asking for it.

However IMNHO it isn't enough to ask for it simply because the version
number has gotten larger.  Packaging takes effort.  A lot of upstreams
(talking random packages here) churn through a lot of releases and not
every release is suitable for packaging.  This can create a lot of
thrash and make-work for packagers.  Therefore packagers often wait
and see and then only package up what ends up becoming the "good
versions" and skipping the ones in between.

Therefore if someone wants a newer version with a BTS wishlist I think
they should say specifically what features or bug fixes they want from
the newer version.  "Version X.Y fixes Bug#123 and includes the new
feature Z."  If they can enumerate out what they want then great.
That adds weight to why a new package should be made (and why in
freeze that the release team should approve the exception).  But if
they can't list anything specific they want from the new version then
that also says something too.

Another point is that asking us here on debian-user is going to get a
lot of opinions none of which matter.  The KDE maintainers are the
ones to ask this question.  They have been maintaining it.  They will
know what they are thinking they will do for the future.  Asking us is
fine but no one except the KDE maintainers will know what they are

Another point is that since Jessie is being prepared for release it
has entered freeze.  That changes the process for upgrades through Sid
Untable into Testing and now requires an exception from the release

> > This is really an extremely simple case.  In order to get a newer
> > version of KDE into Jessie a) someone would need to package it into
> > Debian Unstable which I am sure will happen and b) the release team
> > would need to approve it into Jessie.  Unless the release team
> > approves it Jessie will release with the version that existed at the
> > time of the freeze.  Simple!
> ...asking why these steps would not happen. (Particularly given that
> something at least outwardly similar seems to have happened with GNOME,
> as pointed out in a response by Liam O'Toole.)

Talking about GNOME triggers two comments.  One is that the GNOME
maintainers are not the same people as the KDE maintainers as far as I
know.  The two groups don't need to operate the same.  Most of the
different groups in Debian have their own agenda and operate
differently.  And secondly I will say "enough said" about GNOME and
systemd in Debian.

> Possibly the answer is that it (probably) _will_ happen, or possibly the
> answer is that there are reasons why KDE 4.14.3 is not suitable for a
> freeze exception even though GNOME 3.14.2 was, or possibly the answer is
> something else. (I'm not attempting to address that myself.)

Complete agreement.

> But a flippant response with a generic "because the freeze means no
> updates", which is essentially what I interpret you as having said
> (albeit without as much detail as you gave), does not seem to really
> address the question as I understand it.

I am sorry you read my postings as flippant.  They were not written
flippantly from my perspective.  I created them to be as factual and
as descriptive as I was capable of making them.

It is sometimes hard judgement to make between answering an X-Y
question by answering X or by guessing Y and answering about Y.
I think the real question here is, "Why does Jessie need to freeze?"

For users of Stable the goal is obvious.  It is part of the process of
making a new release.

For users of Testing the freeze is four months of turmoil every two
years.  For most of two years Testing is continuously rolling and
"mostly works".  But then for several months before release during the
freeze the previously known rolling updates stop.  Packages with rc
bugs are agressively removed from Testing.  That feels like a bump in
the road.  Then for a couple of months after release when Testing is
open again there is a flood of new and often disruptive changes that
sometimes break Testing as the backlog of changes flow into Testing.
That time is coming soon next year and definitely feels like a bigger
bump in the road.

Since I think that is the Y part of the original poster's question I
mentioned the Continuously Usable Testing proposal.  It is a different
development process.  Might work.  Might have other unintended
consequences.  These things are hard to predict before being put into

Let's dig a little deeper into this question.  People are often asking
why a release has some version X instead of some other version Y.
Let's think of it like an old fashioned newspaper.  News is happening
all of the time.  How does the newspaper editor decide what goes into
the printing?  An editor can't simply say that the newspaper will
always have the latest news.  At some point the news must actually be
printed.  Before it can be printed the layout of what articles go
where is needed to be determined.  All of the reporters want their
article on the front page and they want it above the fold.  At some
point a news story comes in that is simply too late to make the
printing.  Same thing with any mistakes found.  Late items just can't
go into the newspaper today.  If it is too late it goes into
tomorrow's newspaper.  Or possibly a special edition.  But at some
point the newspaper must actually get printed and at that time any
further news or corrections must go into the next printing.

A software release like Debian Stable is very similar.  At some point
any new version appear too late to make it into the release.  But some
people think it is different because it is an electronic something and
not a physical something.  If it were a web page we could update the
web page every time the user got the page.  But while Debian Stable is
electronic it is more like a newspaper than a web page.  Things break
if they are mismatched.  That requires testing to find the breakage.
It requires effort to fix the bugs.  After bug fixes it requires more
testing.  Before a release that is a couple of months of effort at
least.  That is the freeze.  During that time period external projects
keep going.  And then people ask, but just seconds before the final
Debian Stable release an upstream released another version can that go
into this Debian Stable?  The answer is no it can't.  At some point it
is too late and it misses the window.  Changes like that will need to
go into the next release.  Then people go but what about this very
small targeted thing.  It cures cancer.  It ensures world peace.  Okay
for something that important "stop the presses" and it can go in.
Everything else fits into a judgement call by the release team as
somewhere in between fixing a spelling error and curing cancer.  If it
is significant then it goes in.  If not then it won't.  The release
team is charged with making those judgement calls.

But every one of those changes has the potential to break other
things.  We have often seen examples where security upgrades that
should not have broken anything did break a lot of things.  They are
very rare.  People try really hard not to break things.  But mistakes
happen.  That is why testing is needed after changes.

If you disagree with the above then you are probably going to like the
Continuously Usable Testing proposal because basically that does away
with releases and therefore does away with freezes.  It is a different
development model.  Is it better?  I don't know because we haven't
actually used it yet.  Will it have worse problems?  Maybe.  Again
don't know because it hasn't been implemented yet.  It definitely
values something different.  To me it values Testing more than Stable
where as the current process values Stable more than Testing.  Will it
be implemented?  Maybe.  Maybe not.  I am not a decision maker on the
issue.  But until then we have a freeze about every two years and a
release and then the process repeats.

None of the above was intended to be flippant.


Attachment: signature.asc
Description: Digital signature

Reply to: