Page 1 of 2 12 LastLast
Results 1 to 10 of 22

Thread: Proposed Process Changes For X Server 1.8

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    13,396

    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,091

    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,184

    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,567

    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
    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.

  8. #8
    Join Date
    Aug 2007
    Location
    Europe
    Posts
    401

    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?
    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.

  9. #9
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,567

    Default

    Quote Originally Posted by sabriah View Post
    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?
    Last edited by nanonyme; 09-27-2009 at 06:27 AM.

  10. #10
    Join Date
    Jul 2009
    Posts
    47

    Default

    Quote Originally Posted by sabriah View Post
    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)

Posting Permissions

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