More Broken Promises and Prevarication

[gordboy]

Nope, I said that the code is there and that it works. I didn't say it was "ready", which is something the devs have to decide. And apparently, due to some showstoppers, they decided it wasn't ready for a release.

This doesn't change the fact that you are, indeed, too lazy to download it.

But pingufunkybeat, I have downloaded and compiled the git source. And not just once. Any fool with an hour to spare can do that.

And I hate to say this, but your use of the word "apparently" shows what a dolt you truly are. People have been asking the same question for months.

Could you please tell me which "showstoppers" are holding up the "current" "release" ?

Actually don't bother answering, there are people here with double figure IQs that I am afraid take priority over you.

[bridgman]

For what it's worth, I believe the decision not to insert a major UMS release between 6.12 and 6.13 was correct, since most of the available test coverage had already moved to KMS and so UMS test coverage was already extremely thin. The transition to KMS required some fairly invasive changes to the UMS stack (the "radeon-rewrite" work in mid-2009 which affected Mesa, libdrm and the ddx) in order to let a single copy of the stack operate in both UMS/DRI1 and KMS/GEM/TTM/DRI2 environments during the overlap period, and that introduced a lot of risk.

I believe the intent was to introduce as few other risks as possible during the radeon-rewrite transition, which is why distros were guided towards the bug-fix releases rather than the work-in-process 6.13 code. Even following the lowest risk route there was still some fallout on less-tested GPUs during the fall 2009 distro releases (eg R200 family on Ubuntu 9.10) and it seems to me that the inclusion of higher risk changes would most likely have made things worse.

It's possible that a major release could have been pushed out during the fall of 2009 without major blowups, but based on the magnitude of change and the available testing resources it seems pretty unlikely. That's all guesswork of course, but I *think* the right decisions were made.

Obviously if promises were made during the year about imminent major releases then something was wrong, but I honestly don't remember seeing or hearing any such message from the development community.

[gordboy]

Another One Bites The Dust

my questions to you. did you pay to have the driver released by a certain date?

failing that, were you granted a contract that spelled out the time frame which the driver would be delivered to you?

failing that, do you have some sort of legal agreement without a formal contract that gave reasonable assurance of a delivery date?

well without any of that, the release date is none of your business.

Actually, Dear Child, the release date is *everyones'* business. Everyone who has a stake in maintaining linux, that is. But don't worry, it's not your fault that you don't know this : ignorance is not a crime.

But I must commend your resourcefulness in at least attempting a watertight refutation, even if it was ultimately as bereft of substance as most of the rest of the rubbish in this thread.

[bridgman]

I think we all agree that it's good for everyone to understand release plans, whether they be developers, distro packagers, or users. That said, all of the evidence I have been able to find still points to a consistent message from the developers over the last year, that the next major release would be for KMS after 2.6.33, eg :

http://www.phoronix.com/forums/showthread.php?t=20846

[pingufunkybeat]

Could you please tell me which "showstoppers" are holding up the "current" "release" ?

Oh, but airlied wrote in this very thread that " So far one major R600 AGP bug has been fixed during the RC cycle, and we'd like to make sure no other major ones are lurking."

Apparently, that one. Surely, a programmer with 30 years of experience knows how to read? It's not high-level literature or something. It's not even a git changelog.

[seeker010]

Actually, you have not addressed the point I raised, though I see you cleverly trying to use ad hominem attacks to get around it. The release date is only important for those who have a vested interest, as in those who have most to gain or lose in the long term. As a consumer, you are free to make your choice of OS and GPUs. Nobody is holding a gun to your head and forcing you to use ATI gpus with Linux.

The fact that you decided not to exercise that choice is nobody else's fault. You probably can't help it that logic to you is just a word. You are right, ignorance is not a crime, but it should be. You should educate yourself more.

Actually, Dear Child, the release date is *everyones'* business. Everyone who has a stake in maintaining linux, that is. But don't worry, it's not your fault that you don't know this : ignorance is not a crime.

But I must commend your resourcefulness in at least attempting a watertight refutation, even if it was ultimately as bereft of substance as most of the rest of the rubbish in this thread.

[gordboy]

For what it's worth, I believe the decision not to insert a major UMS release between 6.12 and 6.13 was correct, since most of the available test coverage had already moved to KMS and so UMS test coverage was already extremely thin. The transition to KMS required some fairly invasive changes to the UMS stack (the "radeon-rewrite" work in mid-2009 which affected Mesa, libdrm and the ddx) in order to let a single copy of the stack operate in both UMS/DRI1 and KMS/GEM/TTM/DRI2 environments during the overlap period, and that introduced a lot of risk.

I believe the intent was to introduce as few other risks as possible during the radeon-rewrite transition, which is why distros were guided towards the bug-fix releases rather than the work-in-process 6.13 code. Even following the lowest risk route there was still some fallout on less-tested GPUs during the fall 2009 distro releases (eg R200 family on Ubuntu 9.10) and it seems to me that the inclusion of higher risk changes would most likely have made things worse.

It's possible that a major release could have been pushed out during the fall of 2009 without major blowups, but based on the magnitude of change and the available testing resources it seems pretty unlikely. That's all guesswork of course, but I *think* the right decisions were made.

Obviously if promises were made during the year about imminent major releases then something was wrong, but I honestly don't remember seeing or hearing any such message from the development community.

At last. Something approaching adequacy.

Needless to say I disagree about the Fall 2009 failure to release. This was a big mistake in my view. And that view was most certainly expressed by others, but ignored.

What happened to "release early, release often" ? Do you agree that delaying releases makes things harder to integrate, or are you pleading "special circumstances" ?

But I take your point in the final para about the actual developers and their code of Omerta. I bet you have them firmly in line and reading from the same hymn sheet by now

In the same spirit of compromise that you have so nobly shown, I am willing to change my stance somewhat. So here is my amended question to the congregation :

How many release candidates are planned, and what is the approximate timescale before the actual final release ?

And a final question to you :

Do you agree that hastily thrown together "release candidates" that only appear after vigorous campaigning look shoddy ?

[gordboy]

This Is Not A Bedroom Rig BTW ...

Actually, you have not addressed the point I raised, though I see you cleverly trying to use ad hominem attacks to get around it. The release date is only important for those who have a vested interest, as in those who have most to gain or lose in the long term. As a consumer, you are free to make your choice of OS and GPUs. Nobody is holding a gun to your head and forcing you to use ATI gpus with Linux.

The fact that you decided not to exercise that choice is nobody else's fault. You probably can't help it that logic to you is just a word. You are right, ignorance is not a crime, but it should be. You should educate yourself more.

Better.

But let's talk turkey here. My department has over 50 PCs with radeon cards. This is not something that can be changed on a whim, however tempting that might be. And I did not make that decision in the first place, the cards were bought purely on cost.

Then there is the question of the Spring round of releases. The current candidates for us are Ubuntu 10.04 and Fedora 13. Which gets chosen will ultimately mostly depend on the quality of the graphics support. And that of course, depends on whether there is a release between now and then.

So I fail to see how I do not have a serious interest in this matter.

[airlied]

Better.

But let's talk turkey here. My department has over 50 PCs with radeon cards. This is not something that can be changed on a whim, however tempting that might be. And I did not make that decision in the first place, the cards were bought purely on cost.

Then there is the question of the Spring round of releases. The current candidates for us are Ubuntu 10.04 and Fedora 13. Which gets chosen will ultimately mostly depend on the quality of the graphics support. And that of course, depends on whether there is a release between now and then.

So I fail to see how I do not have a serious interest in this matter.

Neither of those two distros rely on a release date they both ship git the rcs already so if you just stated the problem at the start we could have pointed that out and you wouldn't have had to look like an idiot.

Dave

[linuxist]

my questions to you. did you pay to have the driver released by a certain date?

failing that, were you granted a contract that spelled out the time frame which the driver would be delivered to you?

failing that, do you have some sort of legal agreement without a formal contract that gave reasonable assurance of a delivery date?

well without any of that, the release date is none of your business.

AMEN!

@gordboy First, if you have 30 years of programming experience, why not just add some code to fill the apparently huge gap you claim exists between current git version and future release 6.13? This way you are positively contributing to the open source community; instead you have chosen to be that negative jerk that nobody takes seriously.

Second, are you aware that there is a closed source alternative for ATI cards released by ATI/AMD. They release a new version every month (although most releases don't add much). http://support.amd.com/us/gpudownload/Pages/index.aspx