A Fourth Release Candidate For Mesa 7.5

[nhaehnle]

How is it harming the project? I suspect most of the people who are actually doing the heavy lifting of pushing Mesa's 3D support forward are concentrating on git master anyway. The release schedule doesn't matter for them, unless they are themselves directly involved in the release process or maybe if they're working for a distribution.

The only way it could be seriously harming the project was if it were turning away people who might be interested in joining and helping out. I doubt that this is the case.

Edit: Okay, so it may be bad press, and that shouldn't be entirely shrugged off. But still, you won't get your 3D features at a faster rate just because an arbitrary release schedule is enforced.

[Mr. Anderson]

To come to the point immediately: it is all about bad press. I understand that release schedules cannot always be kept and I think it is better to postpone a release than to enforce it in a broken state. It is an entirely emotional thing. Being enthusiastic about the release in April ("it is out this week"), it is disappointing to still wait for it about three months later. My statistics on reporting bugs about X.org and related software has significantely dropped, because I am pretty disillusioned after waiting for a long time for the new releases of Mesa and X. Yes, the projects do not need my bug reports. But it is the whole "bad press" thing that hurts the project.

[nhaehnle]

Okay, you've convinced me that it hurts the project, because I disagree with you

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.

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)

[Mr. Anderson]

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?

[MostAwesomeDude]

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.

[Mr. Anderson]

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.

[bridgman]

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.

[Mr. Anderson]

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!

[bridgman]

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.

[Ant P.]

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.