Discussion:
How about releasing an update of xorg-x11-drv-intel for Fedora 11
Ilyes Gouta
2009-10-04 09:30:08 UTC
Permalink
Hi,

The title says it all. How about that? We really need it for old intel
h/w such as an i855 for example.

Regards,
Ilyes Gouta.
John Reiser
2009-10-04 15:05:48 UTC
Permalink
Post by Ilyes Gouta
The title says it all. How about that? We really need it for old intel
h/w such as an i855 for example.
Enumerate the reasons, please. Which _specific_ bugs or features have been
improved elsewhere but not in F11? Why are they important to you and others?

--
Ilyes Gouta
2009-10-04 16:36:49 UTC
Permalink
Hi John,

I updated my Fedora 11 laptop (an old Thinkpad R50e, Pentium-M, w/
intel 855G integrated graphics), latest Fedora kernel 2.6.30.8-64 and
I still have the Xv video acceleration locking up the entire machine
as soon as I start a video playback. I dug a bit actually and I'm not
sure anymore if it's the kernel or the intel xorg driver which is
causing this issue (I'd say the former). I'm pretty sure about the
lockup though. I'm going to try gather more information and then may
be report a bug on bugzilla.redhat.com.

-Ilyes
Post by Ilyes Gouta
The title says it all. How about that? We really need it for old intel
h/w such as an i855 for example.
Enumerate the reasons, please. ?Which _specific_ bugs or features have been
improved elsewhere but not in F11? ?Why are they important to you and
others?
--
--
fedora-devel-list mailing list
fedora-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Terry Barnaby
2009-10-07 14:15:06 UTC
Permalink
Post by Ilyes Gouta
The title says it all. How about that? We really need it for old intel
h/w such as an i855 for example.
Enumerate the reasons, please. Which _specific_ bugs or features have been
improved elsewhere but not in F11? Why are they important to you and
others?
The graphics system in F11 is horribly broken for 3D, at least on Intel 845,
ATI 200 and ATI 300 chipsets. Certainly the Blender program will not run
on any of my computers (5 different graphics hardware versions).

I have been using drm/mesa/xf86-video-ati code from GIT to get around this,
but now the XServer is out of date so it has got difficult.
A new release of drm/mesa/xf86-video-ati/Xserver code for F11 based on the
new 1.7 XServer and 7.6 mesa would be very useful.

I understand that changing the Graphics system could break many
users systems, so maybe a build of all the necessary packages could be put
into the testing repository or perhaps a special graphics-testing repository
could be added. This would help get the graphics issues fixed prior to
F12's release ...

It would be good to have a Linux system that could actually to 3D with the
major applications by the end of 2009 !

Cheers


Terry
Bruno Wolff III
2009-10-07 14:41:26 UTC
Permalink
On Wed, Oct 07, 2009 at 15:15:06 +0100,
Post by Terry Barnaby
The graphics system in F11 is horribly broken for 3D, at least on Intel 845,
ATI 200 and ATI 300 chipsets. Certainly the Blender program will not run
on any of my computers (5 different graphics hardware versions).
3d seems to be working better on ATI r530 very recently. (I was finally able
to get glest to run.)
I am upgrading my last F11 machine now to try to get working 3d on my
ATI rv280 even though it will mean a hassle to try to get dahdi-linux
working. The yum update just started, so I might not have the answer
to whether or not 3d is working on that card until tomorrow, but I'll
followup when it is done to indicate whether or not it worked.
I'd really like to be able to test glest without needing a proprietary
driver. (I have some other scrounged machines that have nvidia cards, but
am using them for rawhide testing (including nouveau) and don't want to
mess them up by installing the nvidia drivers.
Josh Boyer
2009-10-07 14:44:10 UTC
Permalink
Post by Terry Barnaby
A new release of drm/mesa/xf86-video-ati/Xserver code for F11 based on the
new 1.7 XServer and 7.6 mesa would be very useful.
No, not really.
Post by Terry Barnaby
I understand that changing the Graphics system could break many
users systems, so maybe a build of all the necessary packages could be put
into the testing repository or perhaps a special graphics-testing repository
could be added. This would help get the graphics issues fixed prior to
F12's release ...
Actually, installing rawhide or the F-12 Beta (or using a livecd) would help
get the graphics issues fixed prior to F-12 release. That is going to help
much more than wasting the developer's time trying to backport everything to
F-11, pushing it to updates-testing, and dealing with all the fallout.
Post by Terry Barnaby
It would be good to have a Linux system that could actually to 3D with the
major applications by the end of 2009 !
Fortunately, F-12 is scheduled for release by then!

josh
Adam Jackson
2009-10-07 18:26:06 UTC
Permalink
Post by Josh Boyer
Post by Terry Barnaby
A new release of drm/mesa/xf86-video-ati/Xserver code for F11 based on the
new 1.7 XServer and 7.6 mesa would be very useful.
No, not really.
Post by Terry Barnaby
I understand that changing the Graphics system could break many
users systems, so maybe a build of all the necessary packages could be put
into the testing repository or perhaps a special graphics-testing repository
could be added. This would help get the graphics issues fixed prior to
F12's release ...
Actually, installing rawhide or the F-12 Beta (or using a livecd) would help
get the graphics issues fixed prior to F-12 release. That is going to help
much more than wasting the developer's time trying to backport everything to
F-11, pushing it to updates-testing, and dealing with all the fallout.
In fact, the major reason for not backporting the intel driver to F11 is
that it requires a bunch of kernel changes that no one really has time
for. Among other things, 830 through 865 require GEM in the intel 2.9,
which we have disabled for the F11 kernel for those chips because (as
shipped) it's utterly broken.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20091007/75f77a9f/attachment.bin
Mail Lists
2009-10-08 02:26:08 UTC
Permalink
Post by Adam Jackson
In fact, the major reason for not backporting the intel driver to F11 is
that it requires a bunch of kernel changes that no one really has time
for. Among other things, 830 through 865 require GEM in the intel 2.9,
which we have disabled for the F11 kernel for those chips because (as
shipped) it's utterly broken.
- ajax
I dont have this hardware - but just a question - why not just upgrade
to upstream (2.6.32 would be nice in a couple of days ... ) ?
Matej Cepl
2009-10-08 07:28:10 UTC
Permalink
Post by Mail Lists
I dont have this hardware - but just a question - why not just upgrade
to upstream (2.6.32 would be nice in a couple of days ... ) ?
I guess because F11 is considered stable release? I don't know really,
but I would just add a banal observation that every hour spend on
backporting stuff to F11 (and from Adam's answer it seems to require many
many hours) cannot be spent on making Rawhide-soon-to-be-F12 more stable
and useful.

Mat?j
Kevin Kofler
2009-10-08 14:36:52 UTC
Permalink
Post by Matej Cepl
I guess because F11 is considered stable release? I don't know really,
but I would just add a banal observation that every hour spend on
backporting stuff to F11 (and from Adam's answer it seems to require many
many hours) cannot be spent on making Rawhide-soon-to-be-F12 more stable
and useful.
The suggestion was not to backport the kernel changes, but to just upgrade
the kernel. The F11 kernel was already upgraded from 2.6.29.4 to 2.6.30.8,
so why not 2.6.31.x or (once it's out) 2.6.32.x?

Kevin Kofler
Terry Barnaby
2009-10-08 09:54:54 UTC
Permalink
Post by Josh Boyer
Post by Terry Barnaby
A new release of drm/mesa/xf86-video-ati/Xserver code for F11 based on the
new 1.7 XServer and 7.6 mesa would be very useful.
No, not really.
Post by Terry Barnaby
I understand that changing the Graphics system could break many
users systems, so maybe a build of all the necessary packages could be put
into the testing repository or perhaps a special graphics-testing repository
could be added. This would help get the graphics issues fixed prior to
F12's release ...
Actually, installing rawhide or the F-12 Beta (or using a livecd) would help
get the graphics issues fixed prior to F-12 release. That is going to help
much more than wasting the developer's time trying to backport everything to
F-11, pushing it to updates-testing, and dealing with all the fallout.
Post by Terry Barnaby
It would be good to have a Linux system that could actually to 3D with the
major applications by the end of 2009 !
Fortunately, F-12 is scheduled for release by then!
josh
Are you confident that F12 will make 3D usable under Linux on the majority of
mainstream graphics cards ?

Due to the range of graphics hardware and the differences between them, I would
have thought that a significant amount of user testing and bug fixing would need
to be done to achieve this. I tried the F12 ATI graphics testing day and
although a good idea the 3D tests were very limited and due to the amount of
effort a user has to put in I guess limited in scope. Although people, myself
included, feed back bugs upstream into the freedesktop GIT repository I would
have thought that a larger audience was required ...

I would have thought that more people would be likely to try out the graphics
updates if it is easy for them to install on their running systems and use in
their normal usage patterns rather than have to maintain a separate test system
just to test and feed back issues ...

It seems that the Fedora short release lifetime makes this sort of testing/bug
fixing for X11 refinement harder.

Anyway I guess this is obviously a trade off between user/testers and developers
time :)
Josh Boyer
2009-10-08 11:20:28 UTC
Permalink
Post by Terry Barnaby
Post by Josh Boyer
Post by Terry Barnaby
It would be good to have a Linux system that could actually to 3D with the
major applications by the end of 2009 !
Fortunately, F-12 is scheduled for release by then!
josh
Are you confident that F12 will make 3D usable under Linux on the majority of
mainstream graphics cards ?
Due to the range of graphics hardware and the differences between them, I would
have thought that a significant amount of user testing and bug fixing
would need to be done to achieve this. I tried the F12 ATI graphics
It is. Which is why we encourage people to test rawhide and Alpha and Beta
releases.
Post by Terry Barnaby
testing day and although a good idea the 3D tests were very limited and
due to the amount of effort a user has to put in I guess limited in
scope. Although people, myself included, feed back bugs upstream into the
freedesktop GIT repository I would have thought that a larger audience
was required ...
A large tester base is needed, yes.
Post by Terry Barnaby
I would have thought that more people would be likely to try out the graphics
updates if it is easy for them to install on their running systems and
use in their normal usage patterns rather than have to maintain a
separate test system
just to test and feed back issues ...
Except that is a major undertaking, and honestly I think it's not what we
should push onto users that are on a stable release. Development happens
in rawhide.
Post by Terry Barnaby
It seems that the Fedora short release lifetime makes this sort of
testing/bug fixing for X11 refinement harder.
Anyway I guess this is obviously a trade off between user/testers and
developers time :)
Yes, and it's also about trying to consolidate as much of the testing effort
as we can.

josh
Bruno Wolff III
2009-10-08 12:51:59 UTC
Permalink
On Thu, Oct 08, 2009 at 10:54:54 +0100,
Post by Terry Barnaby
Are you confident that F12 will make 3D usable under Linux on the majority of
mainstream graphics cards ?
It's not going to provide 3d for nvidia, though it is hoped that nouveau will
be somewhat improved. Intel and all much of ATI (through at least r600 series)
is supposed to get working 3d with kernel mode setting.
Post by Terry Barnaby
Due to the range of graphics hardware and the differences between them, I would
have thought that a significant amount of user testing and bug
fixing would need to be done to achieve this. I tried the F12 ATI
graphics testing day and although a good idea the 3D tests were very
limited and due to the amount of effort a user has to put in I guess
limited in scope. Although people, myself included, feed back bugs
upstream into the freedesktop GIT repository I would have thought
that a larger audience was required ...
So you'd prefer to force F11 users to do testing whether they want to
or not?
Post by Terry Barnaby
I would have thought that more people would be likely to try out the graphics
updates if it is easy for them to install on their running systems
and use in their normal usage patterns rather than have to maintain
a separate test system
just to test and feed back issues ...
It isn't going to be simple to do this. With the modesetting changes there
are a lot of interactions between parts and you need to change a number of
things (X, mesa, drm, kernel) at once to have a working system.
Terry Barnaby
2009-10-08 13:05:22 UTC
Permalink
Post by Bruno Wolff III
On Thu, Oct 08, 2009 at 10:54:54 +0100,
Post by Terry Barnaby
Are you confident that F12 will make 3D usable under Linux on the majority of
mainstream graphics cards ?
It's not going to provide 3d for nvidia, though it is hoped that nouveau will
be somewhat improved. Intel and all much of ATI (through at least r600 series)
is supposed to get working 3d with kernel mode setting.
Post by Terry Barnaby
Due to the range of graphics hardware and the differences between them, I would
have thought that a significant amount of user testing and bug
fixing would need to be done to achieve this. I tried the F12 ATI
graphics testing day and although a good idea the 3D tests were very
limited and due to the amount of effort a user has to put in I guess
limited in scope. Although people, myself included, feed back bugs
upstream into the freedesktop GIT repository I would have thought
that a larger audience was required ...
So you'd prefer to force F11 users to do testing whether they want to
or not?
No, I don't what to force testing on anyone (although F11 has done that
already :) )
I was just suggesting that a separate yum archive with the packages necessary
to test the later graphics development code that will be in F12 could be
made available for people to try out easily with their F11 systems.
They can optionally try these. I think it will allow 3D to work for many people
(from my experience of the latest GIT versions) although others would not be so
lucky. They can easily back these changes out if they have more issues than
the standard graphics system.
Post by Bruno Wolff III
Post by Terry Barnaby
I would have thought that more people would be likely to try out the graphics
updates if it is easy for them to install on their running systems
and use in their normal usage patterns rather than have to maintain
a separate test system
just to test and feed back issues ...
It isn't going to be simple to do this. With the modesetting changes there
are a lot of interactions between parts and you need to change a number of
things (X, mesa, drm, kernel) at once to have a working system.
Yes, there are quite a few changes, that is why it is difficult for people
to test the changes ... Although I would have though that for the most part
it would be just building the appropriate set of the F12 packages for F11.

Ah well, I will probably have to wait for F12 or F13 before I can truly move
from F8 :(
Adam Williamson
2009-10-08 16:37:19 UTC
Permalink
Post by Terry Barnaby
No, I don't what to force testing on anyone (although F11 has done that
already :) )
I was just suggesting that a separate yum archive with the packages necessary
to test the later graphics development code that will be in F12 could be
made available for people to try out easily with their F11 systems.
They can optionally try these. I think it will allow 3D to work for many people
(from my experience of the latest GIT versions) although others would not be so
lucky. They can easily back these changes out if they have more issues than
the standard graphics system.
Then please feel free to make one. :) I don't mean that in a snide
fashion, but it really is the answer. As noted, having our X.org
developers spend time on such a repository directly subtracts that
amount of time from the time they would otherwise spend actually
developing the drivers (our X.org maintainers are also major upstream
developers) and fixing reported bugs.

Given that there is a lot of development work to do on these drivers
(which is why you find the newer versions better...) and a lot of bugs
to fix (we generally barely keep up with the rate of bugs filed as it
is), we don't see that as a good trade-off. You'd get backported drivers
for stable releases, but the rate of development of the actual upstream
drivers would be noticeably slowed, and fewer reported bugs would
ultimately get fixed.

Backporting packages is not intrinsically very difficult, though it is
somewhat time-consuming, so it's something for which a far greater
candidate pool exists than X driver development. Thus, the suggestion
that someone else do it. For instance, you. It seems you've already
successfully built the latest versions of things locally; if you can do
that, you can put them in a package and put the package in a repository,
it's not a very hard process and it's all documented on the Wiki.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
Terry Barnaby
2009-10-08 18:33:01 UTC
Permalink
Post by Adam Williamson
Post by Terry Barnaby
No, I don't what to force testing on anyone (although F11 has done that
already :) )
I was just suggesting that a separate yum archive with the packages necessary
to test the later graphics development code that will be in F12 could be
made available for people to try out easily with their F11 systems.
They can optionally try these. I think it will allow 3D to work for many people
(from my experience of the latest GIT versions) although others would not be so
lucky. They can easily back these changes out if they have more issues than
the standard graphics system.
Then please feel free to make one. :) I don't mean that in a snide
fashion, but it really is the answer. As noted, having our X.org
developers spend time on such a repository directly subtracts that
amount of time from the time they would otherwise spend actually
developing the drivers (our X.org maintainers are also major upstream
developers) and fixing reported bugs.
Given that there is a lot of development work to do on these drivers
(which is why you find the newer versions better...) and a lot of bugs
to fix (we generally barely keep up with the rate of bugs filed as it
is), we don't see that as a good trade-off. You'd get backported drivers
for stable releases, but the rate of development of the actual upstream
drivers would be noticeably slowed, and fewer reported bugs would
ultimately get fixed.
Backporting packages is not intrinsically very difficult, though it is
somewhat time-consuming, so it's something for which a far greater
candidate pool exists than X driver development. Thus, the suggestion
that someone else do it. For instance, you. It seems you've already
successfully built the latest versions of things locally; if you can do
that, you can put them in a package and put the package in a repository,
it's not a very hard process and it's all documented on the Wiki.
I was thinking of doing that, I have done this sort of thing before, until
the drivers/drm/mesa needed changes in the XServer which is dependent on a
lot of things. I would then be fighting a battle with the main updates
repositories for evermore, well until F12 which will then bring in its own
set of problems....
Adam Williamson
2009-10-08 18:39:12 UTC
Permalink
Post by Terry Barnaby
Post by Adam Williamson
Backporting packages is not intrinsically very difficult, though it is
somewhat time-consuming, so it's something for which a far greater
candidate pool exists than X driver development. Thus, the suggestion
that someone else do it. For instance, you. It seems you've already
successfully built the latest versions of things locally; if you can do
that, you can put them in a package and put the package in a repository,
it's not a very hard process and it's all documented on the Wiki.
I was thinking of doing that, I have done this sort of thing before, until
the drivers/drm/mesa needed changes in the XServer which is dependent on a
lot of things. I would then be fighting a battle with the main updates
repositories for evermore, well until F12 which will then bring in its own
set of problems....
well, yes, and that's the exact reason it would be finicky and
time-consuming and not a good way for our X developers to spend their
time :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
Dave Airlie
2009-10-08 23:19:06 UTC
Permalink
Post by Adam Williamson
Post by Terry Barnaby
No, I don't what to force testing on anyone (although F11 has done that
already :) )
I was just suggesting that a separate yum archive with the packages necessary
to test the later graphics development code that will be in F12 could be
made available for people to try out easily with their F11 systems.
They can optionally try these. I think it will allow 3D to work for many people
(from my experience of the latest GIT versions) although others would not be so
lucky. They can easily back these changes out if they have more issues than
the standard graphics system.
Then please feel free to make one. :) I don't mean that in a snide
fashion, but it really is the answer. As noted, having our X.org
developers spend time on such a repository directly subtracts that
amount of time from the time they would otherwise spend actually
developing the drivers (our X.org maintainers are also major upstream
developers) and fixing reported bugs.
I thought about doing something like this the other day, but really
if we had something like Ubuntu PPA, which I think is on the longterm
plans for Fedora then it would be a lot easier to do.

At the moment its just too distracting to do.

The thing with doing updates for F11 is the regression rate due to
lack of QA, I put Mesa packages into updates-testing that fixed a
lot of r300/r500 bugs back at the start of F11 and it went into
testing a few weeks later and broke Intel, I got 0 reports during that
u-t phase about breakage. So now I have a package in stable that
lets 3D works for x num of people and breaks compiz for y number.

So I've pretty much given up on pushing anything to previous Fedora
releases that isn't a security fix or major crash fix, because we simply
don't have the QA in place to avoid regression current users, at least
if you install F11 on your hw, and it doesn't work well, you know that,
if you install it and it works well then later stops working well, thats
a lot worse situation to end up in.

I think for F12 updates we could really do with some sort of side repo
setup, so we could have a stability period where QA could happen on
packages that may end up in updates a month or two later.

Dave.
Post by Adam Williamson
Given that there is a lot of development work to do on these drivers
(which is why you find the newer versions better...) and a lot of bugs
to fix (we generally barely keep up with the rate of bugs filed as it
is), we don't see that as a good trade-off. You'd get backported drivers
for stable releases, but the rate of development of the actual upstream
drivers would be noticeably slowed, and fewer reported bugs would
ultimately get fixed.
Backporting packages is not intrinsically very difficult, though it is
somewhat time-consuming, so it's something for which a far greater
candidate pool exists than X driver development. Thus, the suggestion
that someone else do it. For instance, you. It seems you've already
successfully built the latest versions of things locally; if you can do
that, you can put them in a package and put the package in a repository,
it's not a very hard process and it's all documented on the Wiki.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
James Antill
2009-10-09 03:56:18 UTC
Permalink
Post by Dave Airlie
Post by Adam Williamson
Then please feel free to make one. :) I don't mean that in a snide
fashion, but it really is the answer. As noted, having our X.org
developers spend time on such a repository directly subtracts that
amount of time from the time they would otherwise spend actually
developing the drivers (our X.org maintainers are also major upstream
developers) and fixing reported bugs.
I thought about doing something like this the other day, but really
if we had something like Ubuntu PPA, which I think is on the longterm
plans for Fedora then it would be a lot easier to do.
At the moment its just too distracting to do.
The thing with doing updates for F11 is the regression rate due to
lack of QA, I put Mesa packages into updates-testing that fixed a
lot of r300/r500 bugs back at the start of F11 and it went into
testing a few weeks later and broke Intel, I got 0 reports during that
u-t phase about breakage. So now I have a package in stable that
lets 3D works for x num of people and breaks compiz for y number.
The problem is that PPAs/KoPeRs are going to get much less testing than
stuff in updates-testing, so if you don't think you are getting enough
testing in updates-testing I really don't see how KoPeRs will solve that
problem.

Personally I'd suggest pushing to updates-testing but wait a _long_
time (maybe even never) before pushing to stable.
Of course you are kind of screwed in having a package which might work
fine on one machine, but fail on many others.
Post by Dave Airlie
I think for F12 updates we could really do with some sort of side repo
setup, so we could have a stability period where QA could happen on
packages that may end up in updates a month or two later.
How would this be different from updates-testing? If you install
yum-plugin-aliases it even has predefined aliases lsuT and upT to get
the list of updates from testing, and update to them. bodhi has support
for it etc.
--
James Antill <james at fedoraproject.org>
Fedora
Ben Boeckel
2009-10-09 04:30:37 UTC
Permalink
Post by James Antill
The problem is that PPAs/KoPeRs are going to get much less
testing than
Post by James Antill
stuff in updates-testing, so if you don't think you are
getting enough
Post by James Antill
testing in updates-testing I really don't see how KoPeRs will
solve that
Post by James Antill
problem.
Personally I'd suggest pushing to updates-testing but wait a
_long_
Post by James Antill
time (maybe even never) before pushing to stable.
Of course you are kind of screwed in having a package which
might work
Post by James Antill
fine on one machine, but fail on many others.
Post by Dave Airlie
I think for F12 updates we could really do with some sort of
side repo
Post by James Antill
Post by Dave Airlie
setup, so we could have a stability period where QA could
happen on
Post by James Antill
Post by Dave Airlie
packages that may end up in updates a month or two later.
How would this be different from updates-testing? If you
install
Post by James Antill
yum-plugin-aliases it even has predefined aliases lsuT and upT
to get
Post by James Antill
the list of updates from testing, and update to them. bodhi
has support
Post by James Antill
for it etc.
The problem with forcing two pipelines through u-t for one
package is that if the stable package has something that needs
to go through updates-testing, the new, possibly unstable,
version shadows the new stable build. Side repos (preferably
"themed" per s?; KDE updates separate from GNOME packages that
the same maintainer happens to maintain as well so that users
don't have to update something they use on the side and can't
test as well) is the only way to fit a double pipeline for a
single package through the update system as it stands.

- --Ben
Ilyes Gouta
2009-10-09 08:21:36 UTC
Permalink
Hi,

I actually (think?) that I fixed the issue. It's all related to a
check in the intel i915 drm code in the kernel, which is still present
in the latest Fedora 2.6.30.8-64 kernel. It's in the form of
data->has_gem = !IS_8XX(dev) ? 1 : 0, which gets the whole gem stuff
disabled for my i855GM. I compared with a stock kernel and found that
it was enabled by default for all the intel chips and just reverted
that change (and kept the other redhat patches, such as the mchbar and
the suspend/restore code) and well, it fixed my problem with Xv. I
think that the has_gem thing is exported for X11 and Xv user-space
through a GEM ioctl property and it doesn't interfere with the rest of
the kernel drm code. Anyway, it's working here :) Any confirmation
from redhat's engineers?

Regards,
Ilyes Gouta.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
?The problem is that PPAs/KoPeRs are going to get much less
testing than
stuff in updates-testing, so if you don't think you are
getting enough
testing in updates-testing I really don't see how KoPeRs will
solve that
problem.
?Personally I'd suggest pushing to updates-testing but wait a
_long_
time (maybe even never) before pushing to stable.
?Of course you are kind of screwed in having a package which
might work
fine on one machine, but fail on many others.
Post by Dave Airlie
I think for F12 updates we could really do with some sort of
side repo
Post by Dave Airlie
setup, so we could have a stability period where QA could
happen on
Post by Dave Airlie
packages that may end up in updates a month or two later.
?How would this be different from updates-testing? If you
install
yum-plugin-aliases it even has predefined aliases lsuT and upT
to get
the list of updates from testing, and update to them. bodhi
has support
for it etc.
The problem with forcing two pipelines through u-t for one
package is that if the stable package has something that needs
to go through updates-testing, the new, possibly unstable,
version shadows the new stable build. Side repos (preferably
"themed" per s?; KDE updates separate from GNOME packages that
the same maintainer happens to maintain as well so that users
don't have to update something they use on the side and can't
test as well) is the only way to fit a double pipeline for a
single package through the update system as it stands.
- --Ben
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iQIcBAEBCAAGBQJKzrxtAAoJEKaxavVX4C1XPZwQAKQjQDq6d6ozoTM9s1cOzd7L
nuM4TWe5qkbqORsSW+5o9wimMLlkpfT0LRzZgIdQoc2RJEAj7Tc5/zWeuvmuK8s9
oTje+oZegXnRjnoCmXlnrY0rp1Tsg4RRb6Y2Vk8cI5LIpWgQMn30Bjdigp4NM6TU
qzqnwvE3n1LMaNZuY9ZKRUk8GZOarGcr+vaD46GYV660p2meiPX+jhh1OxLI7Kmt
iSc9lSverigry31im1isEXeXLYT7k3RFBiegzNsNixE25DkCGRu8tPkWZlO6hv//
4t+/iMVkJU+JfUQTnXxdidlPObU3u9aFBgzJfjYentFMYjVH4s0/xnQDQ6UTJN49
AXxYMQExkKDodTYUYBIeSeEAQhFF4cyD0ZzWr9nPeqfB/pZqfv7jAvPJmts2pzKI
u2uRq+L53hOlIjF5fa//514n+n1VuT0ju3gdtBEeAxaVOZfDcXCFEhBAP9KzdNU5
hJ38nwfDulCVbtWRQrs5ks67UXHcDNCb5YSR0vtSjkaJJujUsoiHd7GT+0qsz2NT
6IKRfc86u5+Pn39qhkk0fpQMzlL08GrVIFLK//4EMUOlWiOlZAfRq8Ujx9F4B/+0
H7cZHkix55GMtV6WVQUgBzE0O+rvBDUPfpr/Y2jEdZj2bGbusoowyDms6CF/4DxY
cIK16m8HKZQ0mYZOhgPe
=AIHy
-----END PGP SIGNATURE-----
--
fedora-devel-list mailing list
fedora-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Ilyes Gouta
2009-10-09 09:00:50 UTC
Permalink
Obviously i915.modeset == 0 all the time (including when I reported the issue).

-Ilyes
Post by Ilyes Gouta
Hi,
I actually (think?) that I fixed the issue. It's all related to a
check in the intel i915 drm code in the kernel, which is still present
in the latest Fedora 2.6.30.8-64 kernel. It's in the form of
data->has_gem = !IS_8XX(dev) ? 1 : 0, which gets the whole gem stuff
disabled for my i855GM. I compared with a stock kernel and found that
it was enabled by default for all the intel chips and just reverted
that change (and kept the other redhat patches, such as the mchbar and
the suspend/restore code) and well, it fixed my problem with Xv. I
think that the has_gem thing is exported for X11 and Xv user-space
through a GEM ioctl property and it doesn't interfere with the rest of
the kernel drm code. Anyway, it's working here :) Any confirmation
from redhat's engineers?
Regards,
Ilyes Gouta.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
?The problem is that PPAs/KoPeRs are going to get much less
testing than
stuff in updates-testing, so if you don't think you are
getting enough
testing in updates-testing I really don't see how KoPeRs will
solve that
problem.
?Personally I'd suggest pushing to updates-testing but wait a
_long_
time (maybe even never) before pushing to stable.
?Of course you are kind of screwed in having a package which
might work
fine on one machine, but fail on many others.
Post by Dave Airlie
I think for F12 updates we could really do with some sort of
side repo
Post by Dave Airlie
setup, so we could have a stability period where QA could
happen on
Post by Dave Airlie
packages that may end up in updates a month or two later.
?How would this be different from updates-testing? If you
install
yum-plugin-aliases it even has predefined aliases lsuT and upT
to get
the list of updates from testing, and update to them. bodhi
has support
for it etc.
The problem with forcing two pipelines through u-t for one
package is that if the stable package has something that needs
to go through updates-testing, the new, possibly unstable,
version shadows the new stable build. Side repos (preferably
"themed" per s?; KDE updates separate from GNOME packages that
the same maintainer happens to maintain as well so that users
don't have to update something they use on the side and can't
test as well) is the only way to fit a double pipeline for a
single package through the update system as it stands.
- --Ben
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iQIcBAEBCAAGBQJKzrxtAAoJEKaxavVX4C1XPZwQAKQjQDq6d6ozoTM9s1cOzd7L
nuM4TWe5qkbqORsSW+5o9wimMLlkpfT0LRzZgIdQoc2RJEAj7Tc5/zWeuvmuK8s9
oTje+oZegXnRjnoCmXlnrY0rp1Tsg4RRb6Y2Vk8cI5LIpWgQMn30Bjdigp4NM6TU
qzqnwvE3n1LMaNZuY9ZKRUk8GZOarGcr+vaD46GYV660p2meiPX+jhh1OxLI7Kmt
iSc9lSverigry31im1isEXeXLYT7k3RFBiegzNsNixE25DkCGRu8tPkWZlO6hv//
4t+/iMVkJU+JfUQTnXxdidlPObU3u9aFBgzJfjYentFMYjVH4s0/xnQDQ6UTJN49
AXxYMQExkKDodTYUYBIeSeEAQhFF4cyD0ZzWr9nPeqfB/pZqfv7jAvPJmts2pzKI
u2uRq+L53hOlIjF5fa//514n+n1VuT0ju3gdtBEeAxaVOZfDcXCFEhBAP9KzdNU5
hJ38nwfDulCVbtWRQrs5ks67UXHcDNCb5YSR0vtSjkaJJujUsoiHd7GT+0qsz2NT
6IKRfc86u5+Pn39qhkk0fpQMzlL08GrVIFLK//4EMUOlWiOlZAfRq8Ujx9F4B/+0
H7cZHkix55GMtV6WVQUgBzE0O+rvBDUPfpr/Y2jEdZj2bGbusoowyDms6CF/4DxY
cIK16m8HKZQ0mYZOhgPe
=AIHy
-----END PGP SIGNATURE-----
--
fedora-devel-list mailing list
fedora-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Adam Jackson
2009-10-13 14:16:16 UTC
Permalink
Post by James Antill
Post by Dave Airlie
The thing with doing updates for F11 is the regression rate due to
lack of QA, I put Mesa packages into updates-testing that fixed a
lot of r300/r500 bugs back at the start of F11 and it went into
testing a few weeks later and broke Intel, I got 0 reports during that
u-t phase about breakage. So now I have a package in stable that
lets 3D works for x num of people and breaks compiz for y number.
The problem is that PPAs/KoPeRs are going to get much less testing than
stuff in updates-testing, so if you don't think you are getting enough
testing in updates-testing I really don't see how KoPeRs will solve that
problem.
The problem for X is we have multiple interdependent parts, so if we
actually want to pull in an update we need to get X + kernel + driver +
mesa + libdrm all tagged into a buildroot override. This is... slightly
risky. Kernel is a particularly fun bit, since there are other reasons
why a kernel update would want to go out; you don't want to break drm
for Peter to fix Paul's wireless.

If we were more aggressive about backporting the kernel drm bits, and
there was some slightly easier (preferably Makefile.common-driven) way
of getting a package into the buildroot before being in -updates proper,
we could probably do without lookaside repos.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20091013/27e9c9ba/attachment.bin
Kevin Kofler
2009-10-14 07:03:00 UTC
Permalink
Post by Adam Jackson
If we were more aggressive about backporting the kernel drm bits, and
there was some slightly easier (preferably Makefile.common-driven) way
of getting a package into the buildroot before being in -updates proper,
we could probably do without lookaside repos.
Well, if you ping one of the rel-eng folks on IRC, you'll normally get stuff
tagged with the buildroot override tags fairly quickly.

Kevin Kofler
Kevin Kofler
2009-10-14 06:58:45 UTC
Permalink
Post by James Antill
Personally I'd suggest pushing to updates-testing but wait a _long_
time (maybe even never) before pushing to stable.
"Never" is definitely the wrong answer: updates-testing is not for stuff
which is too unstable to go stable, ever. Any update sitting in testing for
more than (at most) 2 or 3 weeks (usually 1 week is enough, but risky stuff
should get approximately 2 weeks of testing and regression fixing; at least
those are the timings our experience in KDE SIG showed optimal) is either
broken, in which case it should be unpushed (and the maintainer should be
more careful next time), or not, in which case it should be promoted to
stable.

We really need some stricter enforcement against stuff sitting in testing
forever.

Kevin Kofler
Michael Schwendt
2009-10-14 09:21:42 UTC
Permalink
Post by Kevin Kofler
We really need some stricter enforcement against stuff sitting in testing
forever.
Rather we need some rules against such mindset.

We don't guarantee anything about updates-testing. It's a place where
to test potential updates/upgrades. And if a test-update is still without
sufficient karma points (either positive or negative) for several weeks,
it may stay in updates-testing for a longer time. IMO, that's a good
thing.
Adam Williamson
2009-10-14 20:26:53 UTC
Permalink
Post by Michael Schwendt
Post by Kevin Kofler
We really need some stricter enforcement against stuff sitting in testing
forever.
Rather we need some rules against such mindset.
We don't guarantee anything about updates-testing. It's a place where
to test potential updates/upgrades. And if a test-update is still without
sufficient karma points (either positive or negative) for several weeks,
it may stay in updates-testing for a longer time. IMO, that's a good
thing.
I agree with this, but by the same token, the use suggested by Matej
seems against the purpose of updates-testing, as does the original idea
in this thread (push some Xorg changes we'd never be happy about putting
in stable into it). I also agree with Kevin - maybe we don't need to
*disallow* updates sitting in -testing for a long time, but updates
sitting there for a long time is an indication of potential issues and
it should be flagged for tracking.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
Michael Schwendt
2009-10-15 09:26:30 UTC
Permalink
Post by Adam Williamson
(push some Xorg changes we'd never be happy about putting
in stable into it).
If you know that you would _never_ be happy with a test-update becoming
a stable update, then either don't push such a test-update or unpush
it (manually or by relying on karma automatism).

However, it could be that you would need to offer a test-update for two or
more months before you would get essential feedback that helps with
deciding whether it's safe to mark it stable or not.

Especially with regard to version upgrades: if you know the current
package release doesn't suffer from any bugs (as tracked via bugzilla)
and a test-update to a new version may cause regression, why rush and
mark it stable without sufficient feedback? Why force users of stable
updates to become guinea pigs?
Post by Adam Williamson
I also agree with Kevin - maybe we don't need to
*disallow* updates sitting in -testing for a long time, but updates
sitting there for a long time is an indication of potential issues and
it should be flagged for tracking.
0 karma points is "an indication of potential issues"? Not at all.
0 or +1 karma points after a month doesn't make it safe either to mark it
stable. It depends on _who_ contributed _what_ sorts of tests. It may be
that another important tester finds a show-stopper issue three weeks
later. Sometimes we only win a new tester, who would normally avoid
updates-testing like the plague, for a specific test-update while
communicating within a bugzilla ticket. Sometimes not even that, and
all you can get is to have a reporter download a build from koji.

Now tell me how to attract more testers to try updates-testing and enable
it by default on one machine, perhaps a personal desktop. If we continue
to offer test-updates which may "eat babies", as some of you call it, you
can't win much. Not a big problem for kernel test-updates, which aren't
booted by default, but a threat nevertheless. More of a problem for any of
the other packages which get replaced - and there's a steady flood of
packages in updates-testing. One can hear again and again from users that
they don't like "more bleeding-edge" than "stable updates" and that they
expect the package maintainers to give certain guarantees for the
"stability" of updates they offer. No guarantees => let the community
contribute testing. No testing => keep the test-update in updates-testing.
Kevin Kofler
2009-10-15 15:27:33 UTC
Permalink
Post by Michael Schwendt
If you know that you would _never_ be happy with a test-update becoming
a stable update, then either don't push such a test-update or unpush
it (manually or by relying on karma automatism).
That was my point!
Post by Michael Schwendt
However, it could be that you would need to offer a test-update for two or
more months before you would get essential feedback that helps with
deciding whether it's safe to mark it stable or not.
So we only disagree about the timelines. IMHO 2 or more months is way too
long. You should not need that much time to know whether the update is
broken or not! The big problem is that many months is almost
indistinguishible from "never" for all practical purposes. If you enabled
updates from testing, you're still stuck with no upgrade path unless you
stick with testing forever. The main advantage of putting strong time limits
on testing is to provide an upgrade path for one-time testers back to the
stable stream.
Post by Michael Schwendt
0 karma points is "an indication of potential issues"? Not at all.
It is indeed quite the opposite. It's an indication that nobody complained
(unless it's the sum of a "+1 works for me" and a -1 with actual issues), so
it means the update is good to go.

Kevin Kofler
Dave Airlie
2009-10-15 20:48:38 UTC
Permalink
Post by Kevin Kofler
Post by Michael Schwendt
If you know that you would _never_ be happy with a test-update becoming
a stable update, then either don't push such a test-update or unpush
it (manually or by relying on karma automatism).
That was my point!
Post by Michael Schwendt
However, it could be that you would need to offer a test-update for two or
more months before you would get essential feedback that helps with
deciding whether it's safe to mark it stable or not.
So we only disagree about the timelines. IMHO 2 or more months is way too
long. You should not need that much time to know whether the update is
broken or not! The big problem is that many months is almost
indistinguishible from "never" for all practical purposes. If you enabled
updates from testing, you're still stuck with no upgrade path unless you
stick with testing forever. The main advantage of putting strong time limits
on testing is to provide an upgrade path for one-time testers back to the
stable stream.
2 months is too long for user apps maybe, for X.org or Mesa from what I
can see for ever probably isn't long enough, its not a matter of how
much time something spends in updates-testing its a matter of how many
people run what is in there and report on it. We get a lot of QA from
the community on the run-in from Beta to GA, however we get nothing at
all even close post-GA, so finding regressions post-GA is close to
impossible without it hitting updates.

you can get lots of +1s easily finding the -1 that matters is hard.

Dave.
Colin Walters
2009-10-15 21:56:57 UTC
Permalink
Post by Dave Airlie
2 months is too long for user apps maybe, for X.org or Mesa from what I
can see for ever probably isn't long enough
My guess is that it's relatively easy for a semi-technical person to
be able to map back from a visible problem in a desktop app to a
package name, and finally from a package back into the bodhi comments.

But a lot of issues in the core OS from the kernel up to gnome-desktop
can require extensive knowledge to diagnose, and we just can't expect
as much feedback.

Especially for critpath components that people might be more hesitant
to update. Pages like this one:

https://fedoraproject.org/wiki/How_to_debug_Xorg_problems

are a big step forward, but we may need some way for people to give
feedback about updates without having to debug enough to make a rough
stab at "kernel" or "xorg-x11-drv-intel" or "gnome-power-manager".
Bruno Wolff III
2009-10-17 00:29:32 UTC
Permalink
On Fri, Oct 16, 2009 at 06:48:38 +1000,
Post by Dave Airlie
2 months is too long for user apps maybe, for X.org or Mesa from what I
can see for ever probably isn't long enough, its not a matter of how
much time something spends in updates-testing its a matter of how many
people run what is in there and report on it. We get a lot of QA from
the community on the run-in from Beta to GA, however we get nothing at
all even close post-GA, so finding regressions post-GA is close to
impossible without it hitting updates.
you can get lots of +1s easily finding the -1 that matters is hard.
I can't easily give you feedback on stuff because I usually grab new
xorg/mesa/libdrm/kernel stuff from koji. When they finally make it to
updates-testing I am not likely to notice their appearance there.
Someday when 3d graphics fully works again, I'll probably slow down.
Matěj Cepl
2009-10-15 18:26:51 UTC
Permalink
Post by Adam Williamson
I agree with this, but by the same token, the use suggested by Matej
seems against the purpose of updates-testing, as does the original idea
in this thread (push some Xorg changes we'd never be happy about putting
in stable into it). I also agree with Kevin - maybe we don't need to
*disallow* updates sitting in -testing for a long time, but updates
sitting there for a long time is an indication of potential issues and
it should be flagged for tracking.
OK, thanks for clearing my internal conflict for me -- now there would
be no n-2 new packages from me. Simple, easy. (BTW, I always have karma
switched on, but usually nobody bothers to push karma up, so none of my
packages got pushed to stable based on its karma).

Mat?j
--
http://www.ceplovi.cz/matej/, Jabber: mcepl<at>ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC

The state is the great fictitious entity by which everyone seeks
to live at the expense of everyone else.
-- Frederick Bastiat
Adam Williamson
2009-10-15 19:04:09 UTC
Permalink
Post by Matěj Cepl
Post by Adam Williamson
I agree with this, but by the same token, the use suggested by Matej
seems against the purpose of updates-testing, as does the original idea
in this thread (push some Xorg changes we'd never be happy about putting
in stable into it). I also agree with Kevin - maybe we don't need to
*disallow* updates sitting in -testing for a long time, but updates
sitting there for a long time is an indication of potential issues and
it should be flagged for tracking.
OK, thanks for clearing my internal conflict for me -- now there would
be no n-2 new packages from me. Simple, easy. (BTW, I always have karma
switched on, but usually nobody bothers to push karma up, so none of my
packages got pushed to stable based on its karma).
I should've clarified that as far as new packages go, I don't see a
problem with just pushing them to stable after a few days in -testing as
long as no-one complains. It's quite hard for a new package to *break*
something on a currently-working system without explicit action from the
user, which is the worst thing an update can do.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
Kevin Kofler
2009-10-15 23:56:26 UTC
Permalink
Post by Adam Williamson
I should've clarified that as far as new packages go, I don't see a
problem with just pushing them to stable after a few days in -testing as
long as no-one complains. It's quite hard for a new package to *break*
something on a currently-working system without explicit action from the
user, which is the worst thing an update can do.
Right. In fact many packagers just queue new packages directly to stable.

Kevin Kofler
Rahul Sundaram
2009-10-16 08:33:18 UTC
Permalink
Post by Adam Williamson
I should've clarified that as far as new packages go, I don't see a
problem with just pushing them to stable after a few days in -testing as
long as no-one complains. It's quite hard for a new package to *break*
something on a currently-working system without explicit action from the
user, which is the worst thing an update can do.
It is not impossible however and has happened in the past. New packages
can obsolete a existing installed package for example.

Rahul
Adam Williamson
2009-10-16 08:42:13 UTC
Permalink
Post by Rahul Sundaram
Post by Adam Williamson
I should've clarified that as far as new packages go, I don't see a
problem with just pushing them to stable after a few days in -testing as
long as no-one complains. It's quite hard for a new package to *break*
something on a currently-working system without explicit action from the
user, which is the worst thing an update can do.
It is not impossible however and has happened in the past. New packages
can obsolete a existing installed package for example.
That's a point, and in the Grand Plan I'd like to have that heavily
flagged up as potentially dangerous by AutoQA...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
Matěj Cepl
2009-10-14 08:57:09 UTC
Permalink
Post by Kevin Kofler
"Never" is definitely the wrong answer: updates-testing is not for stuff
which is too unstable to go stable, ever. Any update sitting in testing for
more than (at most) 2 or 3 weeks (usually 1 week is enough, but risky stuff
should get approximately 2 weeks of testing and regression fixing; at least
those are the timings our experience in KDE SIG showed optimal) is either
broken, in which case it should be unpushed (and the maintainer should be
more careful next time), or not, in which case it should be promoted to
stable.
We really need some stricter enforcement against stuff sitting in testing
forever.
This is actually your personal opinion AFAIK, right? I tend to disagree
with this -- one example which seems to me legitimate is when I create a
new package (I remember I came to this conclusion with both PSPP and
nimbus-theme) then I sometimes push it into Fedora-[n-1] just for
updates-testing, because I really don't have enough computers to do real
testing on older distros. By that, people who really want it, can take
it and they are implicitly warned that this is not meant to be stable
(generally speaking, I guess, people who follow updates-testing has to
survive some amount of breakage), but it is not thrown on unsuspecting
users of stable.

Mat?j
--
http://www.ceplovi.cz/matej/, Jabber: mcepl<at>ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC

The ratio of literacy to illiteracy is a constant, but nowadays
the illiterates can read.
-- Alberto Moravia
Kevin Kofler
2009-10-15 15:21:42 UTC
Permalink
Post by Matěj Cepl
This is actually your personal opinion AFAIK, right?
No, it's what updates-testing is for.
Post by Matěj Cepl
I tend to disagree with this -- one example which seems to me legitimate
is when I create a new package (I remember I came to this conclusion with
both PSPP and nimbus-theme) then I sometimes push it into Fedora-[n-1]
just for updates-testing, because I really don't have enough computers to
do real testing on older distros.
Who gives a darn? If nobody complains about any issues, just push it! In 99%
of cases, what works fine on Fedora n will work fine on Fedora n-1, too. If
I push a test update to multiple Fedora releases, I always push it to stable
for all affected releases at the same time. The only time it went wrong is
when I pushed something built by another packager who screwed up the
%{?fedora} conditionals (he used "%{?fedora}" string comparisons which broke
for 9 vs. 10, you have to use 0%{?fedora}). That was trivial to fix in the
next push.
Post by Matěj Cepl
By that, people who really want it, can take it and they are implicitly
warned that this is not meant to be stable (generally speaking, I guess,
people who follow updates-testing has to survive some amount of breakage),
but it is not thrown on unsuspecting users of stable.
The problem is, this mindset makes it harder to get people to test things
which ARE headed for stable (which is what updates-testing is for!), because
enabling updates-testing will include a lot of stuff which is not going
stable any time soon. (And selective updates are not the answer, they're a
big can of worms and have caused all sorts of breakage in KDE SIG's
experience.)

Now OK, new packages are not really going to be a problem there, but as new
packages have to be explicitly installed anyway, I don't see what pushing
them to stable can break.

Kevin Kofler
Nicolas Mailhot
2009-10-15 15:51:51 UTC
Permalink
Post by Kevin Kofler
Who gives a darn? If nobody complains about any issues, just push it! In 99%
of cases, what works fine on Fedora n will work fine on Fedora n-1, too.
It is not 99% and it takes just a few bad apples to ruin the experience
provided by the work of many others.

Please do not ever push untested work to stable just because no one
complained. If you want testing on older releases you can push it to testing
but please don't ever promote it.

People who bother to complain when hitting problems are the minority. Others
just decide after a while Fedora is not for them (which is a net loss for us;
just because someone does not have the time to do feedback at some date does
not mean he wouldn't have later)
--
Nicolas Mailhot
Kevin Kofler
2009-10-15 23:49:36 UTC
Permalink
Post by Nicolas Mailhot
Please do not ever push untested work to stable just because no one
complained. If you want testing on older releases you can push it to
testing but please don't ever promote it.
Sorry, letting updates sit in testing forever is just not an option.
Post by Nicolas Mailhot
People who bother to complain when hitting problems are the minority.
It's their loss if they don't report bugs. If it's not in Bugzilla (or Bodhi
comments), it doesn't exist.

Kevin Kofler
Nicolas Mailhot
2009-10-16 08:27:12 UTC
Permalink
Post by Kevin Kofler
Post by Nicolas Mailhot
Please do not ever push untested work to stable just because no one
complained. If you want testing on older releases you can push it to
testing but please don't ever promote it.
Sorry, letting updates sit in testing forever is just not an option.
They won't sit in forever, at worst they'll be pushed to users with the next
Fedora release (that will have been tested properly during beta)
Post by Kevin Kofler
Post by Nicolas Mailhot
People who bother to complain when hitting problems are the minority.
It's their loss if they don't report bugs.
No. It's *our* loss if we needlessly frighten of part of our userbase with a
shoot and forget attitude. I know there have been phases in my life when that
kind of release management would have convinced me to never touch Fedora
again. Then I wouldn't have contributed all I did since. And there are also
many cases (in education for example) where someone that do not contribute any
bug reports, will prescribe Fedora to others that will. Except he'll only do
it if he feels the project is solid.
--
Nicolas Mailhot
Kevin Kofler
2009-10-16 18:39:52 UTC
Permalink
Post by Nicolas Mailhot
They won't sit in forever, at worst they'll be pushed to users with the
next Fedora release (that will have been tested properly during beta)
That's what I mean by "forever". It's "forever" as far as that one release
is concerned.
Post by Nicolas Mailhot
No. It's *our* loss if we needlessly frighten of part of our userbase with
a shoot and forget attitude.
Pushing things which have been tested on at least one Fedora release and
which were in updates-testing for a week or two with no complaints is not
"shoot and forget", it's "I tested it and it worked for me, and nobody else
appears to have any issues with it either, so it's silly to withhold it from
users".

It's the "I'll never update packages in existing/previous releases because I
can't/won't test them myself" attitude which is really "shoot and forget":
"shoot" with the one-time release, "forget" because you won't be updating
it.

For example, I find it sad you switched to fire-and-forget "maintenance" for
dejavu-fonts. The monthly updates were a good thing, they rarely if ever
caused any problems and they improved font coverage.

Kevin Kofler
Nicolas Mailhot
2009-10-16 19:55:02 UTC
Permalink
Post by Kevin Kofler
For example, I find it sad you switched to fire-and-forget "maintenance" for
dejavu-fonts. The monthly updates were a good thing, they rarely if ever
caused any problems and they improved font coverage.
Dejavu has matured a lot so new releases are incremental improvements with no
big feature changes. Not worth it pushing updated packages for previous
releases (that will be installed by pretty much everyone, since DejaVu is in
the default set)

Also, you may have liked the monthly churn, but even lwn.net editors
complained of it publicly

Lastly it gives me more time to work on new packages for new releases.

At the risk of repeating myself one Fedora release cycle is not long and if we
didn't waste our users' time by constant gratuituous updates in stable
releases they could allocate more to update when a new Fedora version was
published.

People who want the latest of everything and do not mind unstability should
run rawhide. Stop rawhidizing stable please.
--
Nicolas Mailhot
Kevin Kofler
2009-10-17 01:49:23 UTC
Permalink
Post by Nicolas Mailhot
Dejavu has matured a lot so new releases are incremental improvements with
no big feature changes.
... i.e. exactly the kind of things which should be pushed as updates!
Post by Nicolas Mailhot
Not worth it pushing updated packages for previous releases (that will be
installed by pretty much everyone, since DejaVu is in the default set)
If there are bugfixes, added glyphs or any other nontrivial change (which
doesn't break things), it probably IS worth pushing.
Post by Nicolas Mailhot
Also, you may have liked the monthly churn, but even lwn.net editors
complained of it publicly
Journalists have nothing better to do than complaining. If they can't
complain about updates, they'll find something else to complain about.
Please listen to actual users, not journalists!
Post by Nicolas Mailhot
Lastly it gives me more time to work on new packages for new releases.
Huh? I do updates for stable releases routinely. It's fairly little work:
just sync the Rawhide changes (by copying the files over the branch ones),
commit, make tag, make build BUILD_FLAGS=--nowait and at some later point in
time, queue the update for testing, then a week later for stable (or just go
directly for stable if there are really just minor changes).
Post by Nicolas Mailhot
At the risk of repeating myself one Fedora release cycle is not long
It's still 6 times as long as some projects', like KDE now (when counting
bugfix releases, the feature cycle is 6 months) or DejaVu in the past! If we
don't push new versions of those projects with monthly releases as updates,
our users have to wait up to half a year (also counting the final freeze) to
get the fixes they've been waiting for, which is completely unnecessary.
Post by Nicolas Mailhot
and if we didn't waste our users' time by constant gratuituous updates in
stable releases they could allocate more to update when a new Fedora
version was published.
I doubt that. Routine updates get done quickly and you can even do other
stuff while they're running. Upgrading to a newer Fedora requires more
planning.
Post by Nicolas Mailhot
People who want the latest of everything and do not mind unstability
should run rawhide.
But what should people who want the latest of everything that doesn't break
things, but do mind instability or feature regressions run? That's exactly
the niche Fedora is targeting (there are plenty of other distros which cater
to the update haters, e.g. RHEL/CentOS, Ubuntu, Debian stable and many
others) and why we're pushing updates to stable releases. The fact that we
aren't doing so consistently is a problem, which is why I'm complaining
about lazy and/or paranoid maintainers like you who aren't participating.
Post by Nicolas Mailhot
Stop rawhidizing stable please.
What I'm suggesting is NOT rawhidizing stable. It's pushing new versions to
stable where they:
* fix bugs,
* possibly add some additional features users have been waiting for,
* DO NOT drop features,
* DO NOT require manual reconfiguration,
* DO NOT break compatibility with existing user data (documents, savegames
etc.),
* DO NOT cause major UI changes (but I think minor UI changes are fine!),
* DO NOT knowingly introduce new bugs (e.g. in KDE SIG, we make it a high
priority to fix all known regressions before promoting a KDE update to
stable; but the important point there is that we can't fix what we don't
know about).

These criteria are very different from Rawhide or upgrading to the next
release! But a lot of version upgrades (and dejavu-fonts is part of those)
fulfill those requirements and should thus be pushed!

Kevin Kofler
Matěj Cepl
2009-10-15 18:22:22 UTC
Permalink
Post by Kevin Kofler
Post by Matěj Cepl
This is actually your personal opinion AFAIK, right?
No, it's what updates-testing is for.
Yes, that's your personal opinion about what updates-testing is for.
Post by Kevin Kofler
Who gives a darn? If nobody complains about any issues, just push it!
Yes, I know, that's opinion of people around KDE that they don't
distinguish between Rawhide and updates-testing (I am very glad I left
KDE world in 3.* timeframe), but I don't agree with this (and that's MY
personal opinion). Unless, I would be (mis-?)using updates-testing as I
described, I wouldn't be pushing new packages into [n-2] distros at all.

Mat?j
Kevin Kofler
2009-10-15 23:54:15 UTC
Permalink
Post by Matěj Cepl
Yes, I know, that's opinion of people around KDE that they don't
distinguish between Rawhide and updates-testing
That's not true. In KDE SIG:
* we do not push KDE prereleases to updates-testing (nor to the stable
updates, of course),
* we rarely push application prereleases to updates-testing (and when we do,
it's with the intention of promoting them to stable, or the final release
(or a later prerelease) which is just days (not months) away),
* we do not push updates which make major changes (e.g. feature regressions)
to applications, neither to testing nor stable.

Rawhide does get all that stuff (unless we're in a freeze period), as does
kde-redhat unstable.

Kevin Kofler
Rahul Sundaram
2009-10-16 08:37:30 UTC
Permalink
Post by Kevin Kofler
Post by Matěj Cepl
Yes, I know, that's opinion of people around KDE that they don't
distinguish between Rawhide and updates-testing
* we do not push KDE prereleases to updates-testing (nor to the stable
updates, of course),
* we rarely push application prereleases to updates-testing (and when we do,
it's with the intention of promoting them to stable, or the final release
(or a later prerelease) which is just days (not months) away),
* we do not push updates which make major changes (e.g. feature regressions)
to applications, neither to testing nor stable.
Well, I do remember spending hours switching from kmail to thunderbird
in the past because a KDE update in Fedora broke IMAP support and it
stayed broken for quite sometime. Also many of the KDE apps after a
rewrite tend to be quite close to alpha/beta releases for a while rather
than general releases, Amarok being a good example. It is sometimes
pretty tricky to judge.

Rahul
Kevin Kofler
2009-10-16 18:47:38 UTC
Permalink
Post by Rahul Sundaram
Well, I do remember spending hours switching from kmail to thunderbird
in the past because a KDE update in Fedora broke IMAP support and it
stayed broken for quite sometime.
There have indeed been a few KMail regressions (especially with IMAP) which
slipped through, both in 3.5 times and in early 4.x times. I'll also clarify
that none of those regressions completely "broke IMAP support". What
happened is that some IMAP-related feature broke, affecting some users (and
I'm sorry you were hit by it), whereas most had their IMAP working just
fine. So those bugs weren't trivial to catch. I'm not claiming we're
perfect, nor that upstream KDE is. That said, we haven't had such issues
recently, so things seem to have improved there on the upstream side.
Post by Rahul Sundaram
Also many of the KDE apps after a rewrite tend to be quite close to
alpha/beta releases for a while rather than general releases, Amarok being
a good example. It is sometimes pretty tricky to judge.
The Amarok rewrite was NOT pushed as an update. Fedora 9 stayed with 1.4.x
until Fedora 9's EOL. On the other hand, Fedora 10 shipped with a beta of
2.0 (for similar reasons as why F11 shipped with a Thunderbird beta: we knew
that the 2.0 release would be close, that upgrading from 1.4 to 2.x in
updates wasn't really an option and that 1.4 was being EOLed by upstream)
and tracked 2.0.x, 2.1.x and now 2.2.x, which were all incremental
improvements, not rewrites.

Kevin Kofler
James Antill
2009-10-19 04:04:58 UTC
Permalink
Post by Kevin Kofler
What
happened is that some IMAP-related feature broke, affecting some users (and
I'm sorry you were hit by it), whereas most had their IMAP working just
fine. So those bugs weren't trivial to catch.
Wow ... it's almost as if we need a place where developers could put
_updates_ for a significant amount of time so that users could do some
_testing_ on them, under each of their particular conditions. We could
maybe use this instead of developers hitting the go button when they
didn't get an avalanche of BZs immediately.

It'd also be cool if we could have some package management tool to
"downgrade" these updates, so users wouldn't be immediate screwed if
they tried an update for testing purposes ... it might even be possible
to create a history of package management operations, and then the user
could just "undo" the set of things they got from this place for testing
of updates.

I must meditate on this.
--
James Antill - james at fedoraproject.org
"I'd just like to see a realistic approach to updates via
packages." -- Les Mikesell
Kevin Kofler
2009-10-21 06:49:35 UTC
Permalink
Post by James Antill
Wow ... it's almost as if we need a place where developers could put
_updates_ for a significant amount of time so that users could do some
_testing_ on them, under each of their particular conditions. We could
maybe use this instead of developers hitting the go button when they
didn't get an avalanche of BZs immediately.
We use updates-testing very carefully in KDE SIG. But many users only start
trying out updates when they go stable, no matter how long they've been in
testing. :-( So some bugs will always slip through the cracks (and not just
in KDE). Any testing repository will by definition only be used by testers,
i.e. by a rather small subset of our userbase.

But I think that overall, our updates are a good thing. They aren't perfect,
but no software is! And if you read the complaints about Vi$ta service packs
rendering some systems unbootable, it's not like our competition is doing
any better. AFAIK, we haven't had serious breakage like those KMail IMAP
issues for a while now.

Kevin Kofler

Terry Barnaby
2009-10-09 08:35:23 UTC
Permalink
Post by Dave Airlie
Post by Adam Williamson
Post by Terry Barnaby
No, I don't what to force testing on anyone (although F11 has done that
already :) )
I was just suggesting that a separate yum archive with the packages necessary
to test the later graphics development code that will be in F12 could be
made available for people to try out easily with their F11 systems.
They can optionally try these. I think it will allow 3D to work for many people
(from my experience of the latest GIT versions) although others would not be so
lucky. They can easily back these changes out if they have more issues than
the standard graphics system.
Then please feel free to make one. :) I don't mean that in a snide
fashion, but it really is the answer. As noted, having our X.org
developers spend time on such a repository directly subtracts that
amount of time from the time they would otherwise spend actually
developing the drivers (our X.org maintainers are also major upstream
developers) and fixing reported bugs.
I thought about doing something like this the other day, but really
if we had something like Ubuntu PPA, which I think is on the longterm
plans for Fedora then it would be a lot easier to do.
At the moment its just too distracting to do.
The thing with doing updates for F11 is the regression rate due to
lack of QA, I put Mesa packages into updates-testing that fixed a
lot of r300/r500 bugs back at the start of F11 and it went into
testing a few weeks later and broke Intel, I got 0 reports during that
u-t phase about breakage. So now I have a package in stable that
lets 3D works for x num of people and breaks compiz for y number.
So I've pretty much given up on pushing anything to previous Fedora
releases that isn't a security fix or major crash fix, because we simply
don't have the QA in place to avoid regression current users, at least
if you install F11 on your hw, and it doesn't work well, you know that,
if you install it and it works well then later stops working well, thats
a lot worse situation to end up in.
I think for F12 updates we could really do with some sort of side repo
setup, so we could have a stability period where QA could happen on
packages that may end up in updates a month or two later.
Dave.
Post by Adam Williamson
Given that there is a lot of development work to do on these drivers
(which is why you find the newer versions better...) and a lot of bugs
to fix (we generally barely keep up with the rate of bugs filed as it
is), we don't see that as a good trade-off. You'd get backported drivers
for stable releases, but the rate of development of the actual upstream
drivers would be noticeably slowed, and fewer reported bugs would
ultimately get fixed.
Backporting packages is not intrinsically very difficult, though it is
somewhat time-consuming, so it's something for which a far greater
candidate pool exists than X driver development. Thus, the suggestion
that someone else do it. For instance, you. It seems you've already
successfully built the latest versions of things locally; if you can do
that, you can put them in a package and put the package in a repository,
it's not a very hard process and it's all documented on the Wiki.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
I totally agree with you on the QA issue. Maybe I am wrong, but I haven't
seen any real set of tests to be performed on Fedora 3D graphics.
I tried the ATI test day for graphics. On the 3D graphics side it said to
run "glxgears" and if you like other 3D apps that you use. Running your
other 3D apps is difficult from a limited Live distribution...
I really think a simple test procedure should be implemented and documented
to at least check for basic functionality with the main 3D applications.
Ideally an automatic test program should be part of this.
This would allow a relative novice to test the 3D system on their hardware
and hopefully automatically feed back constructive results from the
myriad of different graphics hardware options.
Andreas Tunek
2009-10-09 12:08:41 UTC
Permalink
Post by Terry Barnaby
Post by Dave Airlie
Post by Adam Williamson
Post by Terry Barnaby
No, I don't what to force testing on anyone (although F11 has done that
already :) )
I was just suggesting that a separate yum archive with the packages necessary
to test the later graphics development code that will be in F12 could be
made available for people to try out easily with their F11 systems.
They can optionally try these. I think it will allow 3D to work for many people
(from my experience of the latest GIT versions) although others would not be so
lucky. They can easily back these changes out if they have more issues than
the standard graphics system.
Then please feel free to make one. :) I don't mean that in a snide
fashion, but it really is the answer. As noted, having our X.org
developers spend time on such a repository directly subtracts that
amount of time from the time they would otherwise spend actually
developing the drivers (our X.org maintainers are also major upstream
developers) and fixing reported bugs.
I thought about doing something like this the other day, but really
if we had something like Ubuntu PPA, which I think is on the longterm
plans for Fedora then it would be a lot easier to do.
At the moment its just too distracting to do.
The thing with doing updates for F11 is the regression rate due to
lack of QA, I put Mesa packages into updates-testing that fixed a
lot of r300/r500 bugs back at the start of F11 and it went into
testing a few weeks later and broke Intel, I got 0 reports during that
u-t phase about breakage. So now I have a package in stable that
lets 3D works for x num of people and breaks compiz for y number.
So I've pretty much given up on pushing anything to previous Fedora
releases that isn't a security fix or major crash fix, because we simply
don't have the QA in place to avoid regression current users, at least
if you install F11 on your hw, and it doesn't work well, you know that,
if you install it and it works well then later stops working well, thats
a lot worse situation to end up in.
I think for F12 updates we could really do with some sort of side repo
setup, so we could have a stability period where QA could happen on
packages that may end up in updates a month or two later.
Dave.
Post by Adam Williamson
Given that there is a lot of development work to do on these drivers
(which is why you find the newer versions better...) and a lot of bugs
to fix (we generally barely keep up with the rate of bugs filed as it
is), we don't see that as a good trade-off. You'd get backported drivers
for stable releases, but the rate of development of the actual upstream
drivers would be noticeably slowed, and fewer reported bugs would
ultimately get fixed.
Backporting packages is not intrinsically very difficult, though it is
somewhat time-consuming, so it's something for which a far greater
candidate pool exists than X driver development. Thus, the suggestion
that someone else do it. For instance, you. It seems you've already
successfully built the latest versions of things locally; if you can do
that, you can put them in a package and put the package in a repository,
it's not a very hard process and it's all documented on the Wiki.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
I totally agree with you on the QA issue. Maybe I am wrong, but I haven't
seen any real set of tests to be performed on Fedora 3D graphics.
I tried the ATI test day for graphics. On the 3D graphics side it said to
run "glxgears" and if you like other 3D apps that you use. Running your
other 3D apps is difficult from a limited Live distribution...
I really think a simple test procedure should be implemented and documented
to at least check for basic functionality with the main 3D applications.
Ideally an automatic test program should be part of this.
This would allow a relative novice to test the 3D system on their hardware
and hopefully automatically feed back constructive results from the
myriad of different graphics hardware options.
Maybe we could do a "Phoronix live cd" that includes the phoronix 3d
tests and removes stuff like abiword and gnumeric?
Post by Terry Barnaby
--
fedora-devel-list mailing list
fedora-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Josh Boyer
2009-10-09 12:30:41 UTC
Permalink
Post by Andreas Tunek
Maybe we could do a "Phoronix live cd" that includes the phoronix 3d
tests and removes stuff like abiword and gnumeric?
If the tests are in Fedora and you find someone willing to create the
kickstart file for the spin, sure.

josh
Adam Williamson
2009-10-09 14:57:51 UTC
Permalink
Post by Andreas Tunek
Maybe we could do a "Phoronix live cd" that includes the phoronix 3d
tests and removes stuff like abiword and gnumeric?
We're not huge fans of the Phoronix tests for a variety of reasons
(including that you don't really have a clue what it's installing most
of the time). It would be nice to have more comprehensive 3D tests.
Frankly, the reason they're so rudimentary ATM is that even basic 3D
functionality is broken in sufficient numbers of cases to keep the
developers busy...basic 3D or Compiz was broken in the majority of cases
in both the Intel and Radeon test days this time around (although I
think those bugs are fixed now). But if people want to contribute more
extensive 3D test cases, that would be awesome, and the kind of
contribution we'd love to have to the QA group.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
Scott Tsai
2009-10-10 15:02:32 UTC
Permalink
Post by Adam Williamson
It would be nice to have more comprehensive 3D tests.
I think it's worth packaging the "piglit" OopenGL test suite:
http://cgit.freedesktop.org/piglit
and using it in graphics test days.

According tho this blog post by Eric Anholt and the git commit log,
upstream open source graphics driver developers are still constantly
adding tests to it:
http://anholt.livejournal.com/41522.html
Adam Williamson
2009-10-10 15:15:53 UTC
Permalink
Post by Scott Tsai
Post by Adam Williamson
It would be nice to have more comprehensive 3D tests.
http://cgit.freedesktop.org/piglit
and using it in graphics test days.
According tho this blog post by Eric Anholt and the git commit log,
upstream open source graphics driver developers are still constantly
http://anholt.livejournal.com/41522.html
Good point. I think Francois Cami had some plans to this effect, but
he's been away from the project for a few months lately, so maybe I'll
do it instead. Thanks for the reminder.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
Bruno Wolff III
2009-10-09 16:15:46 UTC
Permalink
On Fri, Oct 09, 2009 at 09:35:23 +0100,
Post by Terry Barnaby
I totally agree with you on the QA issue. Maybe I am wrong, but I haven't
seen any real set of tests to be performed on Fedora 3D graphics.
I tried the ATI test day for graphics. On the 3D graphics side it said to
run "glxgears" and if you like other 3D apps that you use. Running your
other 3D apps is difficult from a limited Live distribution...
Try the games spin. I have a related problem in that it is hard for me as
the spin maintainer to test the 3d games on the spin because the stock
drivers haven't been supporting 3d on any of my machines at home. And
3d testing on my work machine (which also hasn't worked real well) is
pretty limited to testing that 3d works on that machine, not really the
kind of testing of the spin that I'd like to do to test the spin itself.
Post by Terry Barnaby
I really think a simple test procedure should be implemented and documented
to at least check for basic functionality with the main 3D applications.
I am supposed to be doing test cases for the games spin. That isn't going to
get done for F12 though.
Post by Terry Barnaby
Ideally an automatic test program should be part of this.
This would allow a relative novice to test the 3D system on their hardware
and hopefully automatically feed back constructive results from the
myriad of different graphics hardware options.
Bruno Wolff III
2009-10-08 17:49:28 UTC
Permalink
On Thu, Oct 08, 2009 at 14:05:22 +0100,
Post by Terry Barnaby
I was just suggesting that a separate yum archive with the packages necessary
to test the later graphics development code that will be in F12 could be
made available for people to try out easily with their F11 systems.
They can optionally try these. I think it will allow 3D to work for many people
It is probably just as good for the user to try out rawhide and see if it
is worth going to F12. And it's a lot less work for developers and graphics
seems to have a developer bottleneck, so I think savign their effort is
beneficial to the project.
Jesse Keating
2009-10-08 15:11:23 UTC
Permalink
Post by Terry Barnaby
I would have thought that more people would be likely to try out the graphics
updates if it is easy for them to install on their running systems and use in
their normal usage patterns rather than have to maintain a separate test system
just to test and feed back issues ...
This is why live images are useful. Boot the live image, do some of
your normal work, throw it away when done and don't disrupt your already
installed OS.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20091008/2b8c93d8/attachment.bin
Bruno Wolff III
2009-10-08 17:59:18 UTC
Permalink
On Wed, Oct 07, 2009 at 15:15:06 +0100,
Post by Terry Barnaby
The graphics system in F11 is horribly broken for 3D, at least on Intel 845,
ATI 200 and ATI 300 chipsets. Certainly the Blender program will not run
on any of my computers (5 different graphics hardware versions).
I was able to start testing my rv280 based ATI 9200 card this morning
and I was able to do stuff in tremulous, so it looks like 3d is working
again. For F11 I had needed to use no modeset which broke 3d.

I still have some more testing to do and I need to set up at least one
modeline since modeline detection doesn't work for me (probably because
my monitor doesn't do EDID correctly or at all).

So it might be worth you trying out F12. Note that I used a very recent
kernel and ati driver which might not have been tagged for the beta.
This seemed to be an improvement over my first reboot after going to
F12 which had stuff a day or so older.

I am going to be very happy if this preliminary result bears out under
further testing.
Michal Nowak
2009-10-05 09:40:50 UTC
Permalink
Post by Ilyes Gouta
Hi John,
I updated my Fedora 11 laptop (an old Thinkpad R50e, Pentium-M, w/
intel 855G integrated graphics), latest Fedora kernel 2.6.30.8-64 and
Well, having i855 here too, and frankly, xorg-x11-drv-intel+libdrm+kernel
combination at F-11 was really horrible one. Upgrading to Rawhide seems to
fixed it. I don't see any crash/hang for a some time.
Post by Ilyes Gouta
I still have the Xv video acceleration locking up the entire machine
as soon as I start a video playback.
Well, Xv's still now working at all when KMS is enabled (and when is
disabled the whole system hangs at start :).

But there's patch http://bugs.freedesktop.org/show_bug.cgi?id=20901
you might wanna test it -- looked good.
Post by Ilyes Gouta
I dug a bit actually and I'm not
sure anymore if it's the kernel or the intel xorg driver which is
causing this issue (I'd say the former).
Indeed. Perhaps you may try to rebuild Rawhide kernel for F-11 and
test it? (Not that I knew what happens when you do so.)
Post by Ilyes Gouta
I'm pretty sure about the
lockup though. I'm going to try gather more information and then may
be report a bug on bugzilla.redhat.com.
-Ilyes
Michal
Post by Ilyes Gouta
On Sun, Oct 4, 2009 at 4:05 PM, John Reiser <jreiser at bitwagon.com>
Post by Ilyes Gouta
The title says it all. How about that? We really need it for old
intel
Post by Ilyes Gouta
h/w such as an i855 for example.
Enumerate the reasons, please. ?Which _specific_ bugs or features
have been
improved elsewhere but not in F11? ?Why are they important to you
and
others?
--
--
fedora-devel-list mailing list
fedora-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
fedora-devel-list mailing list
fedora-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Michal Nowak
2009-10-06 09:17:46 UTC
Permalink
Post by Michal Nowak
But there's patch http://bugs.freedesktop.org/show_bug.cgi?id=20901
you might wanna test it -- looked good.
As of now it's "RESOLVED FIXED". Should be part of 2.6.32 kernel (when
is out).

Michal
chasd
2009-10-09 16:22:33 UTC
Permalink
It's Friday, so I'll allow myself to digress -
Post by Ilyes Gouta
think that the has_gem thing is exported for X11 and Xv user-space
through a GEM ioctl property and it doesn't interfere with the rest of
Whenever I see " GEM " I get weird DOS GUI flashbacks, and they hurt.
Couldn't they have called it something else ?
( Not expecting an answer )
--
Charles Dostale
Continue reading on narkive:
Loading...