Proposed Process Changes For X Server 1.8

[phoronix]

Phoronix: Proposed Process Changes For X Server 1.8

While the X.Org developers are responsible for a lot of critical code and much of it is quite old and massive, they are often challenged by hitting a release on time and often face multiple release schedules before coming close to delivering a new X Server / X.Org release. Just take a look at X.Org 7.4 Finally Released, X.Org 7.5 Released...

http://www.phoronix.com/vr.php?view=NzU2Mw

[d2kx]

These sound like excellent proposals to me. It's just a stupid thing to keep delaying a release because one of the many new features isn't ready but it is being developed in the git master.

[DanL]

Kudos to Mr. Hutterer for grabbing this massive, raging bull by the horns.

[loonyphoenix]

I'm shocked something like this wasn't proposed sooner. Those look like rather obvious things.

[val-gaav]

This way Xorg, KDE , GNOME would have the same 6 month release cycle... If only those would be synced to happen at the same time :D ... Would be so nice...

[nanonyme]

Yeah and if only all features took as long to be written and if only all coders wrote code as fast and... Oh, wait, it's impossible in practice? :o

[rohcQaH]

I'm shocked something like this wasn't proposed sooner. Those look like rather obvious things.
yes, maybe. But the problem wasn't figuring out that there are problems with the releases. The problem was that nobody stepped up to feel responsible for the releases, to grab the related work and do it.

Peter does exactly that, and that's a good thing.

This way Xorg, KDE , GNOME would have the same 6 month release cycle... If only those would be synced to happen at the same time :D ... Would be so nice...
Having everyone release at the same time sounds good at first, but instantly upgrading every piece of software in a system rarely goes well, because nobody had a chance to test their release against everyone else's release beforehand. Imagine all those projects releasing today, and ubuntu just puts the new version on an iso and releases, too!

There has to be a sliding schedule, with the bottom of the stack releasing first, then the one next up. After an xorg release, the KDE/GNOME devs want some time to test their code against the new xorg before releasing. After the KDE/GNOME-Releases, the distros want some testing before shipping. etc


but all that is only important if you care about half-yearly time-based distro releases. I personally don't (gentoo), but many do.

[another_sam]

I love this proposal. I think it adapts terribly well to the nature of free software building; both for the effects on the project itself and for the effects on the rest of the projects that depend on it.

So, I think this idea should be not only implemented at X.org but also copied by other free software projects.

I think chaos can be tamed on the free software ecosystem thanks to this techniques. And if we achieve that, a resonance effect will emerge producing a wave of freedom that will smash window panes all across Microsoft offices. FUCK YES!

[Game_boy]

Yeah and if only all features took as long to be written and if only all coders wrote code as fast and... Oh, wait, it's impossible in practice? :o

If a feature isn't ready in time, it isn't merged in during that window. Each release of X.Org will have the features that become stable during its development period. This works for every other FOSS project with time-based releases.

[another_sam]

Having everyone release at the same time sounds good at first, but instantly upgrading every piece of software in a system rarely goes well, because nobody had a chance to test their release against everyone else's release beforehand. Imagine all those projects releasing today, and ubuntu just puts the new version on an iso and releases, too!

There has to be a sliding schedule, with the bottom of the stack releasing first, then the one next up. After an xorg release, the KDE/GNOME devs want some time to test their code against the new xorg before releasing. After the KDE/GNOME-Releases, the distros want some testing before shipping. etc


but all that is only important if you care about half-yearly time-based distro releases. I personally don't (gentoo), but many do.

I share your observations but not the conclusion. I think there is an optimal solution: To share release frequency, but offsetting stack levels by the alpha stage. So each team starts to develop over closed APIs.

This means that for (e.g.) Ubuntu 10.10 development to be started by May, apps should be in beta by May. And for apps development to be started by February, its components should be in beta by February. And so on.

Well, probably real life is more complex than that, but I think that if it makes sense conceptually, we should be able to manage ourselves to make it happen.

[sabriah]

Yeah and if only all features took as long to be written and if only all coders wrote code as fast and... Oh, wait, it's impossible in practice? :o

No, it isn't impossible in practice. The fglrx drivers of AMDT/ATI for the Radeon cards have released like this for about two years now, with monthly releases.

Yes, we can read frustrated chief editors claiming "nothing exiting this month" etc. But, so what. They release. And they release smaller and gradual improvements more often, and, larger and more involving changes as well, but less often. Like it is expected to be.

So, I think this step is in the correct direction.

[Gen2ly]

For years I've been waiting for a clipboard that remembers clips after I close an app. Finally, possibly there is hope.

[nanonyme]

No, it isn't impossible in practice. The fglrx drivers of AMDT/ATI for the Radeon cards have released like this for about two years now, with monthly releases.You mean with these bug-free and well-tested monthly releases that no one ever complains about? :)
Seriously though, we all know that's a moronic example. People have to resort to betas of future versions because monthly releases just don't suffice. Sure, if everyone used X.org as git snapshots too, we wouldn't have all this hassle with versions. But as it is, you seem to be more forgiving on AMD/ATi developers for not delivering features in time for releases than X.org. Why's that?

[sabriah]

[...] you seem to be more forgiving on AMD/ATi developers for not delivering features in time for releases than X.org. Why's that?

Because I have worked as a developer and I know hard it can be to deliver... :)

Guess why I don't work as one any longer. ;)

I do still code, but not for someone else.

[fabiank22]

Yes, we can read frustrated chief editors claiming "nothing exiting this month" etc. But, so what. They release. And they release smaller and gradual improvements more often, and, larger and more involving changes as well, but less often. Like it is expected to be.


This makes NO sense. Sorry, but X.org, whether you take only the X-Server or X.org, is at a point where the main thing people complain about is missing features/unstable performance.

Let's try this from another viewpoint: What is your reason for upgrading to X-Server 1.7? Stability? Really? What got people excited was the possibilities of Multi-Pointer-X, and even that didn't make it completely.

I don't really get upgrading for upgradings sake. Bug-fix-releases are still happening, as 1.7.x. There is NO need to bump version-numbers and Apis without having anything interesting to show for.

Seeing how the X-Server has been growing for a few years, there's always a lot of old code involved when something like XInput or pciaccess gets reworked, so I personally would love it if they would wait with their releases till all the infrastructure gets reworked to deal with the changes completely, instead of bothering with releases that do just enough of the transition to not break this to badly(for example XInput 1.5 vs 2.0)

[sabriah]

This makes NO sense. Sorry, but X.org, whether you take only the X-Server or X.org, is at a point where the main thing people complain about is missing features/unstable performance.

Let's try this from another viewpoint: What is your reason for upgrading to X-Server 1.7? Stability? Really? What got people excited was the possibilities of Multi-Pointer-X, and even that didn't make it completely.

I don't really get upgrading for upgradings sake. Bug-fix-releases are still happening, as 1.7.x. There is NO need to bump version-numbers and Apis without having anything interesting to show for.

Seeing how the X-Server has been growing for a few years, there's always a lot of old code involved when something like XInput or pciaccess gets reworked, so I personally would love it if they would wait with their releases till all the infrastructure gets reworked to deal with the changes completely, instead of bothering with releases that do just enough of the transition to not break this to badly(for example XInput 1.5 vs 2.0)

In the case of fglrx, I have some right to complain, as I have paid for the hardware (even if my pet OS isn't officially supported)

In the case of X, I am not so sure to whom I have the "right" to complain. Still, stability, performance, and features are also on my wishlist.

The "X-men" need support, not complaints.

[nanonyme]

Because I have worked as a developer and I know hard it can be to deliver... :)You completely and utterly missed my point, I think. My point was that you should be more forgiving on X.org developers. Everyone seems to be expecting pretty much miracles from them, then settling for a lot less for eg AMD/ATi developers. (who you took as an example for monthly releases and I took as an example of how monthly releases do not actually work) How is that fair? Why should we expect X.org developers somehow magically would start getting features done if they got strict deadlines even though no one else does? (the developers who have strict deadlines release unfinished and immature software, period; you have to wait for them to finish what they're doing and then release, not the other way around)

[sabriah]

You completely and utterly missed my point, I think. My point was that you should be more forgiving on X.org developers. Everyone seems to be expecting pretty much miracles from them, then settling for a lot less for eg AMD/ATi developers. (who you took as an example for monthly releases and I took as an example of how monthly releases do not actually work) How is that fair? Why should we expect X.org developers somehow magically would start getting features done if they got strict deadlines even though no one else does? (the developers who have strict deadlines release unfinished and immature software, period; you have to wait for them to finish what they're doing and then release, not the other way around)

Ok, so we agreed all the time! :)

Yes, and the point I was trying to make that if you release at regular intervals users can anticipate their releases. If it includes some feature, fine. If not, they can wait if they like to.

The point would be that there would always be a release, every six months or so. If a feature is not included in time. Ok, fine, we'll have to wait another six months, even if the feature was finished a few days later.

Besides, even in a monthly release schedule, ATI does have a fairly wide window of 30 days. Some months it is released around the 21st, other months earlier or later. It is not carved in stone.

Follow the release cycle of of KDE 4. I think that was a nice example of how it could be done.

If a feature wasn't ready in time it was pushed to the next release.

"Early and often" seems to be the mantra - since a long time http://www.catb.org/~esr//writings/homesteading/cathedral-bazaar/ar01s04.html.

It appears you get more gradual changes using that style, and less api changes etc. But, I haven't followed the development of X too well to really judge. Armchair Judge? Maybe. ;)

[nanonyme]

Guess what kind of feedback X.org would start getting from Michael if they started going with the "release early, release often" mantra? ;)
"Yet another X.org monthly release with no new features." "No significant features this month either." etc. So instead of complaining that X.org doesn't do releases we'd start getting complaints that releases don't contain anything. Solution: shut the people up and let developers do their stuff. ;)

[sabriah]

Guess what kind of feedback X.org would start getting from Michael if they started going with the "release early, release often" mantra? ;)
"Yet another X.org monthly release with no new features." "No significant features this month either." etc. So instead of complaining that X.org doesn't do releases we'd start getting complaints that releases don't contain anything. Solution: shut the people up and let developers do their stuff. ;)

Here we agree again!

BTW, I wonder what kind of suits the X-men have. Hmmm... :cool:

[DeepDayze]

This way Xorg, KDE , GNOME would have the same 6 month release cycle... If only those would be synced to happen at the same time :D ... Would be so nice...

If all those things hit at the same time, you'd better be prepared for a massive download at update time. I would prefer staggering the releases of the X server, desktop and kernel to give the distros a chance to test the new packages and put them in their repos

[mirv]

Leaving aside any issues of what's best for development, etc etc etc, I personally just think it's great to see that they're going to try do something to improve the release cycle of X. Hope it all works out ok.