Benjamin wrote a comment on my last post, and I’ll share my answers here because those questions come up every now and then, so it’s better to try to inform everyone. (That and I never write on this blog, so this is a perfect excuse to do so)
If you assume compile problems, why is that thing unmasked?
Xorg-server 1.7 is not getting stabilized, it’s just getting unleashed onto unstable. Unstable means exactly that. Of course we try to do our best and we won’t release something we know will break. The idea behind unstable is for users to test the new and shiny stuff before it hits stable.
If you don’t want to help fix bugs, use stable. It’s as simple as that.
I’ve always been irritated by the way the xorg team handled masked/unstable/stable releases, as even rc’s were unmasked at times.
Releases in X-land are tough. The numbers almost mean nothing. For instance, the last stable version in the 1.5 series was 1.5.3-r6. And despite the apparently stable version number, it currently has 80 patches to make it run smoothly.
On the opposite side, the current stable server is 1.6.3.901-r2, which is indeed a “pre point release” only has a couple patches. And 1.7.1 doesn’t have any patches.
So don’t let the version number fool you, they mean almost nothing.
As for what we put in portage, well X is a complex piece of software. It used to have more than a million lines of code and it’s been getting some tough love these last 2 or 3 years. And up until recently, drivers were a mess. I had shivers every time a new driver was released : “How many systems will this break?” was a question I asked myself over and over.
There are probably a lot of people who put the xorg-server in package.keywords because they needed/wanted feature X/Y or because it fixed some bug for them (it did for me). So now I get a release that possibly breaks build in unstable?
Again, unstable is for power users who are not afraid of filing bug reports if something breaks. We try to make sure that things don’t break every day, but Gentoo being a source distro with billions of possibilities (USE flags, CFLAGS, arches, packages, …),you can’t reasonably expect us to try every possible combination.
So we ask for you help (via bugzilla) in return. Gentoo is a community distro, after all.
So there, that’s it for today, I hope y’all know a bit more about how we manage X and unstable packages.
Stable for stable.
Unstable for not stable yet (testing).
It seems to *me* like there is nothing to change.
BUT if people always complain about that, we should AT LEAST study the problem, TRY to find a “solution” to their problem…
Maybe you could create an other branch named “bleedingedge”. It would contain hot “almost stable” versions of “important” packages (like X, firefox, kde, etc) using as less unstable libs as possible…
It’s purpose would be to let people have a more “up to date” environnement and/or use more recent versions “fixing bugs”…
Is it too complicated? Too “expensive” to make?
I feel honoured by such a lengthy response. Let me just point out a few things:
– I very much accept your explanation that version number don’t mean much in the xserver. As such, my irritiation was unjustified, at least when pointed at you or the gentoo-devs.
– I actually file quite a number of bugs all the time. I used to be a gentoo-dev but quit because of lack of time (I don’t want to get too emotional about it, but I just want to let you know that I quite know what I’m talking about)
That sentence really struck me: “The ABI of X libraries has not changed, but I’m pretty sure there will be compile errors in some packages”
The more I think about it, the more I understand what you tried to say, but when I read it the first time, my feeling was: well, when you upgrade, things will badly break very likely. And that’s not the way unstable works. Unstable is a place where things in large are settled, but are not yet finalized and some minor breakage still can happen. May be that’s the message you tried to get across?
Rémi: Yes, that’s what I meant. The ABI is unchanged (meaning currently built packages will still work) but headers have moved around (meaning that new builds may fail). That’s where I’m asking for both help and a little indulgence 🙂
If every unstable package would break in many cases, people would not use it.
>> you can’t reasonably expect us to try every possible combination
No, surely not, sir! I know that’s not possible and would never expect that
Cheers
Benjamin
Keep doing what you are doing.
Thanks for the prompt addition of Xorg 7.5!
I just wanted to say that I really appreciate your work, and that I was really excited when I found you that released such a large package on the same day as it was officially released. Thanks, and keep up the great work!
Hi,
Thanks for the effort on keeping up with X.
Also, keeping it cool and civil is a great way to respond to -positive and negative- criticism. After all, people criticise because they give importance and want things to be better.
Nice post. Yes, we shouldn’t break the ~arch tree on purpose..But it seems like people just want a second stable tree which doesn’t help us with much. But it does point out that the arch teams are overworked because they can’t keep up (or we are not filing stablereqs in a timely manor, etc)
@Jeremy: I think it varies from arch-to-arch. However, x86 & amd64 are arches that should be easy to find ATs for.
This is how ~arch has to be. The not infrequently demanded “stability” and problem-free operation of ~arch is ridiculous.
What should be expected is one-two different compiles and possibly running through an automated test suite, not developers wasting his precious time trying to get things polished even BEFORE it hits real installations.
That duty must be moved to the larger amount of installations and the overall massively larger time budget of ~arch users. This is the only efficient way to produce a stable branch, after all…
not to forget, that you can’t and shouldn’t fix ”upstream” in the distro. as a distro you just serve ”upstream” as best as possible to your users. .