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 planning. 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 team. > > 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 service. 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. Bob
signature.asc
Description: Digital signature
