Page 1 of 3 123 LastLast
Results 1 to 10 of 22

Thread: Proposed Process Changes For X Server 1.8

  1. #1
    Join Date
    Jan 2007
    Posts
    14,787

    Default Proposed Process Changes For X Server 1.8

    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

  2. #2
    Join Date
    Jan 2007
    Location
    Germany
    Posts
    2,132

    Default

    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.

  3. #3
    Join Date
    Oct 2007
    Posts
    1,273

    Default

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

  4. #4
    Join Date
    Jan 2009
    Posts
    80

    Default

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

  5. #5
    Join Date
    Dec 2007
    Posts
    248

    Default

    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 ... Would be so nice...

  6. #6
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,595

    Default

    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?

  7. #7
    Join Date
    Nov 2008
    Posts
    767

    Default

    Quote Originally Posted by loonyphoenix View Post
    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.

    Quote Originally Posted by val-gaav View Post
    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 ... 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.

  8. #8
    Join Date
    Dec 2008
    Posts
    16

    Default

    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!

  9. #9
    Join Date
    Oct 2007
    Posts
    25

    Default

    Quote Originally Posted by nanonyme View Post
    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?
    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.

  10. #10
    Join Date
    Dec 2008
    Posts
    16

    Default

    Quote Originally Posted by rohcQaH View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •