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

Thread: X.Org 7.5 Release Schedule Slips Again

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    15,138

    Default X.Org 7.5 Release Schedule Slips Again

    Phoronix: X.Org 7.5 Release Schedule Slips Again

    X.Org 7.5 with the X Server 1.7 update has been delayed, again. X.Org 7.5 was originally scheduled for release in early April but that ended up being an April Fool's Day joke...

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

  2. #2
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,187

    Default

    Heh

    Cheers,
    Daniel

    (PS: Hi Phoronix!)
    (PS: Hi Daniel!)
    Then on the delay itself, sucks, but it's nice that time-based schedules don't overrun the feature based plans.

  3. #3
    Join Date
    Jul 2008
    Posts
    869

    Default time based releases

    Why do they stick on feature-driven releases. Xorg is in the open source world one of the biggest mess.

    The last Ubuntu-version showed it again, the intel-driver is not stable and have some regressions, that stinks.
    With git its no big deal to manage a seperate branch for new stuff and manage the old codebase as long as the new stuff dont work without regressions.

    So whats the problem with a release without new major featurer, updated drivers and some fixes are enough.

    But release-cycles like xorg 7.4 stinks.

    And by the way all this fuckin firms who earn much money with linux could pay some developer for this project. its the bottleneck of the open source world.

  4. #4
    Join Date
    May 2008
    Posts
    45

    Default

    Quote Originally Posted by blackiwid View Post
    Why do they stick on feature-driven releases.
    Why? Because they have a feature plan for the release. I personally prefer the version X contains Y features over the version X is released on y.mm Ultimately the reason is that projects like Ubuntu and Wine don't use the feature release cycle is because the model doesn't fit.

  5. #5
    Join Date
    Nov 2008
    Posts
    776

    Default

    Quote Originally Posted by he_the_great View Post
    Wine don't use the feature release cycle is because the model doesn't fit.
    Wine uses a feature-based release cycle. There was a clear set of goals for 1.0, and it wasn't released until they were met. The're a list of features for the next wine release (1.2), but no time yet. See http://wiki.winehq.org/WineReleasePlan

    the bi-weekly stuff you see are development snapshots, not releases.

  6. #6
    Join Date
    May 2008
    Posts
    45

    Default

    Quote Originally Posted by rohcQaH View Post
    Wine uses a feature-based release cycle. There was a clear set of goals for 1.0, and it wasn't released until they were met. The're a list of features for the next wine release (1.2), but no time yet. See http://wiki.winehq.org/WineReleasePlan

    the bi-weekly stuff you see are development snapshots, not releases.
    Not exactly. Snap shots don't have version numbers, and their 1.0 release did not meet the blocking bug requirements but did the date scheduled.

  7. #7
    Join Date
    Jan 2009
    Location
    UK
    Posts
    331

    Default

    Quote Originally Posted by blackiwid View Post
    Why do they stick on feature-driven releases.
    So they release something that works.

    If you're offended by that, maybe you should go use a distro that doesn't bother getting it right before releasing. I believe Ubuntu almost has working sound these days.

  8. #8
    Join Date
    Jul 2006
    Posts
    86

    Default

    all that matters to me is that opensuse 11.2 includes the new X.org.

  9. #9
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,187

    Default

    I'd have to say that ever since the modularization, there's absolutely no need to put out a release just to have updated drivers and fixes.

    Want 7.4 with an updated driver X? Just get 7.4, and then the source for driver X, and soon you have a Xorg release from after 7.4, with fixes and a newer driver.


    On Ubuntu's latest Intel mess, isn't that the fault of time-based releasing? If they could've waited for a better Intel driver, things would have been smoother. Or picked an older version if they just had to release at date Y.

  10. #10
    Join Date
    Feb 2008
    Posts
    15

    Default

    Quote Originally Posted by curaga View Post
    I'd have to say that ever since the modularization, there's absolutely no need to put out a release just to have updated drivers and fixes.

    Want 7.4 with an updated driver X? Just get 7.4, and then the source for driver X, and soon you have a Xorg release from after 7.4, with fixes and a newer driver.


    On Ubuntu's latest Intel mess, isn't that the fault of time-based releasing? If they could've waited for a better Intel driver, things would have been smoother. Or picked an older version if they just had to release at date Y.
    I've been becoming more and more convinced of the following every day. The latest Ubuntu Intel Mess (TM) is a very clever way to do releases. Releasing broken Intel drivers is without a doubt, the best and most sure-fire way to get them fixed as quickly as possible. Especially with a huge userbase the size of Ubuntu's.

    Say, for the sake of example, 1/3 of Ubuntu's users were affected because they were using Intel drivers, that's going to annoy a lot of people. Both the kernel, and the driver devs will be hounded into fixing them asap.

    And the real cost? Ubuntu breaks on 1/3 of existing machines, for a single 6-month release which is already established as a bleeding-edge release. Compare that to Microsoft who break 3/3 people's computers every 7 years when they release things like Vista.

    Everyone knew the Intel drivers were broken before the release, I did at least. The solution was not to upgrade, LTS is LTS for a reason. 6 months is a very short amount of time, average users don't upgrade every 6 months, not in my experience anyway.

    The cost of breaking everything for 6 months compared to how quickly it will prompt things to be fixed is without a doubt an incredibly efficient way to drive development. Much more efficient than the proprietary model in my opinion.

Posting Permissions

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