Announcement

Collapse
No announcement yet.

A Fourth Release Candidate For Mesa 7.5

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • bridgman
    replied
    Given that everyone now uses a CM tool which handles branches well (git) and the broad availability of packaged builds off development code (edgers) it's not clear that the traditional "unstable releases of Mesa" are actually needed any more.

    I don't think the problem is broken archives, but rather that the developers understood what was going on and so no announcement was felt to be required. The mailing lists are aimed at developers, not users; AFAIK the official public schedule is still "when it's ready".

    Anything else is usually either (a) original target dates discussed in the context of making content/schedule decisions, or (b) informal "today my guess is..." comments made by folks involved in development, where those comments take on a life of their own and eventually get (wrongly) regarded as plans or commitments.
    Last edited by bridgman; 14 July 2009, 03:10 PM.

    Leave a comment:


  • Mr. Anderson
    replied
    Originally posted by bridgman View Post
    So, in short words, the 7.5 release being worked on now is what was originally called 7.6, and was later called 7.5.1. I'm not 100% sure of this but it seems pretty likely.
    I see… that's a different impression than I had and explains pretty much. I thought it was meant as "7.5 will be released as planned, but instead of 7.6 being a stable follower of 7.5, this will be 7.5.1 etc. while 7.6 can be branched from master with all the new stuff right after the first 7.5 release".

    Originally posted by bridgman View Post
    The problem here, I think, was that there never was a formal announcement that 7.5 was becoming something completely different; I think the change of plans just sort of oozed out into the development community.
    The mailing lists archives on sourceforge seem to be somewhat broken. It is hard to get accurate information (or at least was, maybe it has been fixed now). So: yes, such an announcement would have been helpful.
    Last edited by Mr. Anderson; 14 July 2009, 01:56 PM.

    Leave a comment:


  • bridgman
    replied
    In fairness, nobody ever "promises", you just make the best guess you can under the circumstances. The problem here, I think, was that there never was a formal announcement that 7.5 was becoming something completely different; I think the change of plans just sort of oozed out into the development community.

    If you look at the 7.5 branch activity, the largest number of changes (albeit the smallest ones) happened between rc3 and rc4, which makes sense for a stable release but not for 7.5 as it was originally planned.

    Leave a comment:


  • Ant P.
    replied
    in a Phoronix article back in April: Gallium3D-Capable Mesa 7.5 Release This Week!
    Well, to be blunt, there's your problem: it's a Phoronix article. The actual message made no such promises at all.
    Last edited by Ant P.; 14 July 2009, 01:30 PM.

    Leave a comment:


  • bridgman
    replied
    Yeah, I think those plans changed almost immediately though, if you follow the mailing list thread in the article :

    http://sourceforge.net/mailarchive/f...ame=mesa3d-dev

    What the thread says, in essence, is that the release model for Mesa changed. Rather than 7.5 being a "get the code out but don't consider it stable" release and 7.6 being the stable release, the plan changed so that a 7.5 branch would be created and 7.5.1 would be the stable release, created off the 7.5 branch. At some point it seems that there was an unspoken decision to make 7.5 rather than 7.5.1 the stable release and skip the unstable 7.5 release entirely.

    So, in short words, the 7.5 release being worked on now is what was originally called 7.6, and was later called 7.5.1. I'm not 100% sure of this but it seems pretty likely.
    Last edited by bridgman; 14 July 2009, 01:26 PM.

    Leave a comment:


  • Mr. Anderson
    replied
    It began with this:

    Brian Paul of Tungsten Graphics (now owned by VMware) announced today that he intends to release Mesa 7.5 in the coming days. Specifically, he hopes to release Mesa 7.5 this Friday. It hasn't been that long since Mesa 7.3 has been released (let alone Mesa 7.4), but the 7.5 release is imminent. Brian explains, "I'm looking at making the 7.5 release on Friday. The main objective of this development release will be an initial milestone / roll-out of the Gallium bits. Then, I'd like to quickly create the Mesa 7.6 branch for stabilization. git/master will then again be open to any/all development."
    in a Phoronix article back in April: Gallium3D-Capable Mesa 7.5 Release This Week!

    Leave a comment:


  • bridgman
    replied
    Is it possible that the Mesa 7.5 and Xorg 7.5 schedules are being mixed up here ?

    I remember reading about an April schedule for Xorg 7.5, based on "four months after xserver 1.6" but I don't remember reading anything about a Mesa 7.5 schedule.

    Leave a comment:


  • Mr. Anderson
    replied
    Originally posted by MostAwesomeDude View Post
    Because 3D drivers are hard to write and even harder to make stable.
    I have no doubt about that. But IMO it is better not to make promises (publish schedules) that can not be kept.

    Leave a comment:


  • MostAwesomeDude
    replied
    Originally posted by Mr. Anderson View Post
    The disappointment does not come from slow releaes. It comes from schedules that are postponed again and again. Why are schedules being published if you can not at least roughly rely on them?
    Because 3D drivers are hard to write and even harder to make stable.

    Leave a comment:


  • Mr. Anderson
    replied
    Originally posted by nhaehnle View Post
    Here's why: the project *does* need bug reports - at least high quality ones, I'm just going to assume that that's what you provided.
    I try my best, collecting any information that might be useful. Bringing a problem down to a *really* simple testcase is usually too hard for me, because I do not know enough about X.org and time is unfortunately limited.

    If the bad release managment turns you away from doing that, then yes, it hurts the project. (Note that, depending on the type of bug, it is usually necessary that you're prepared to build Git mesa, or maybe at least run -edgers packages or whatever your distro equivalent is. If you're prepared to do that, then maybe you shouldn't be that disappointed about slow releases? Just a suggestion - and I realize that running bleeding edge stuff isn't for everyone)
    Principally it is ok for me to try things with bleeding edge code from git or other versioning systems. But using the latest final release is currently not an option with some packages, because they cause bad problems with my hardware. Once I had a problem with my graphics driver. I did not report the problem in the bug tracker of my distribution, because it seemed to be an upstream bug. I could bisect it and reported it in the freedesktop bug tracker. It was fixed within three days. So I went to the bug tracker of my distribution and described the bug and linked the upstream bug report with the fix. They did not backport the fix because the next release was scheduled to be out within the next days. Actually it took nearly a month until the release was out and another two weeks until it was in the distribution repositories.

    Another problem with git sources: not seldom I run into new problems when using vanilla sources, because my distribution has patched something. In such a case I do not know if a missing patch is causing the problem or if the checked out code is broken on my system configuration. Then applying the distribution patches sometimes fails because they are not compatible. Sometimes I try to apply a patch manually, but things may get even worse then, because I do not know the code. Furthermore it might be possible that I should use code from git from the project itself and several of its dependencies (e.g. Linux kernel master git). This all costs pretty much time and when a new problem shows up, it might be caused by one of half a dozen bleeding edge components. Also I have to update this git stuff manually and can not rely on the update mechanism of my distribution.

    The disappointment does not come from slow releaes. It comes from schedules that are postponed again and again. Why are schedules being published if you can not at least roughly rely on them?

    Leave a comment:

Working...
X