> https://bugzilla.redhat.com/197033 > > It has been enough time to downgrade the driver or request more feedback > from users who are hit hard by this. But what has happened instead? The > "bugzilla > /dev/null" syndrom again. Zero interest in avoiding this > serious regression compared with FC5. > > I'm not impressed. Actually, I'm in really bad mood, and that is the > case seldomly. Well, for one thing, it's still marked NEEDINFO, so the assignee may not still be expecting feedback.

Michael Schwendt wrote: > On Thu, 05 Oct 2006 09:12:45 -0500, Rex Dieter wrote: > >>> https://bugzilla.redhat.com/197033 >>> >>> It has been enough time to downgrade the driver or request more feedback >>> from users who are hit hard by this. But what has happened instead? The >>> "bugzilla > /dev/null" syndrom again. Zero interest in avoiding this >>> serious regression compared with FC5. >>> >>> I'm not impressed. Actually, I'm in really bad mood, and that is the >>> case seldomly. >> Well, for one thing, it's still marked NEEDINFO, so the assignee may not >> still be expecting feedback. > > https://bugzilla.redhat.com/203570 is still in NEW and doesn't look > anything like encouraging either. You want another ticket filed just to > see it closed as duplicate? Or is this some kind of educational measure, > because Mike Harris wants Fedora X breakage reported upstream? :-} The bare fact is, that the majority of bugs in the X server and/or video drivers, are bugs in the X.Org codebase as shipped by the X.Org foundation. Regardless of what one's own personal thoughts/feelings are about where they would like to or should file a bug report, it is an indisputable fact that reporting a bug in any piece of software to the place which will reach the widest possible audience of developers who can potentially fix the issue, is going to maximize the likelihood of the issue being fixed sooner rather than later. That is true no matter what distribution you are using, what the particular piece of software is, or which developer maintains that software. Since developer resources are finite, this fact is all the more important. Even more so when it comes to hardware issues rather than general case software issues in random userland software, as many hardware related bug reports such as for the kernel and X server, quite often will require the person investigating the issue to have the exact hardware on hand and be able to reproduce it. That of course assumes that they can justify spending the time on a given issue when they take all of their assigned priorities into account, which is not always the case. I'm being quite open and honest when I say that something has to give somewhere. You either delay an OS release indefinitely until your finite manpower can investigate all bugs that are reported and fix them, or you ship an OS with many bugs not fixed. By having people report issues directly to the source of the problem (the upstream projects), it maximizes the eyeballs on the problem, both on the developer side, and the people reporting the issue side, and vastly increases the likelyhood of an issue getting fixed sooner than later. Now I fully understand that some people can be greatly frustrated when a developer tells them to report the bug they've reported to upstream. I too sometimes feel frustrated when someone has told me to do that, so I can fully relate. But the logic inherent in what I've said above holds true even for myself, and so upstream is often the best place to report a bug period. Now, whether one _wants_ to do that, or things they should _have_ to do that or not is totally up to the individual. Nobody has a gun to their head. When a Red Hat engineer asks someone to report an issue upstream, they're doing so because they genuinely want to see the issue resolved, and they know that by the person reporting it upstream the likelihood of that being accomplished increases, thus parallelizing development/maintenance and making the software better for all users, even those who use other operating system distributions. People can debate the merits of this if they like, but you can't get 500 miles per gallon out of a 33 mpg vehicle. Hope this helps others to understand why developers sometimes ask users to report bugs upstream, and that it is done for the good of all, even if it is sometimes slightly inconvenient for the one(s) reporting the issue in the first place.

Take care, TTYL -- fedora-test-list mailing list fedora-test-list(a)redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list

On Tue, 2006-10-10 at 15:57 -0400, Ernest L. Williams Jr. wrote: > Forgive me, if I ask a dumb/newbie question. > What does it mean by upstream? The Company/Vendor/Person/Domain/Site/whatever who develops the program itself. In other words, upstream=where the program is released from before the developers/companies get it.

-- Mike Chambers Madisonville, KY "It's only funny until someone gets hurt, then it's hilarious!"

tir, 10 10 2006 kl. 15:57 -0400, skrev Ernest L. Williams Jr.: > Forgive me, if I ask a dumb/newbie question. > What does it mean by upstream? Generally this means the source of the product, e.g. the Apache project being upstream for the apache package. The gain of getting fixes upstream naturally being that the problem is solved for everyone at once and downstream (in this case the Fedora project) doesn't have to carry and support a patch, a counterproductive and wasteful way to spend our time.

- David Nielsen

On Thursday 05 October 2006 10:08, Michael Schwendt wrote: > https://bugzilla.redhat.com/197033 > > It has been enough time to downgrade the driver or request more feedback > from users who are hit hard by this. But what has happened instead? The > "bugzilla > /dev/null" syndrom again. Zero interest in avoiding this > serious regression compared with FC5. Perhaps you could provide the log file that the maintainer is looking for and still hasn't received.

On Thursday 05 October 2006 13:40, Michael Schwendt wrote: > As long as I get the feeling that I'm ignored or that I will be flamed > again for adding comments or attachments to other person's tickets, I wait > for clear instructions before flooding bugzilla with too many details > which are not requested. 'again' ?

In this case, the RH employee reporting the bug is no different from random schmo off the street reporting the bug. The maintainer needed certain information to continue, which is why the bug is marked as NEEDINFO.

Before that information is provided, however it is provided, the bug cannot be worked on and other bugs, which have the needed info, will be worked on instead. If we held up every release so that every piece of hardware worked perfectly, we'd never release the product.

> Initial reporter has not responded yet. A comment from me did not clear > the NEEDINFO state. When you add a comment, there is a checkbox for 'I am providing the requested information for this bug.'. Until that checkbox is cleared, the bug sits in NEEDINFO state.

Neither of these bugs were put on FC6Blocker, which anybody with a bugzilla account could have done, so it hasn't gotten any other 'supervisorial' eyes on it.

On Thursday 05 October 2006 13:40, Michael Schwendt wrote: > As long as I get the feeling that I'm ignored or that I will be flamed > again for adding comments or attachments to other person's tickets, I wait > for clear instructions before flooding bugzilla with too many details > which are not requested. 'again' ? In this case, the RH employee reporting the bug is no different from random schmo off the street reporting the bug. The maintainer needed certain information to continue, which is why the bug is marked as NEEDINFO. Before that information is provided, however it is provided, the bug cannot be worked on and other bugs, which have the needed info, will be worked on instead. If we held up every release so that every piece of hardware worked perfectly, we'd never release the product.

On Thursday 05 October 2006 22:03, Jim Cornette wrote: > With a broken text installer and limiting the ability for the user to > run the graphical installer successfully, consideration on not releasing > a distro would be a wise decision. Where's the bug for the broken text installer? I'm pretty sure that 'linux video=vesa' still works too, to force the vesa driver, which according to the reporter does give some gui support.

On Thu, 2006-10-05 at 22:37 -0400, Jim Cornette wrote: > On Thu, 2006-10-05 at 22:12 -0400, Jesse Keating wrote: >> On Thursday 05 October 2006 22:03, Jim Cornette wrote: >>> With a broken text installer and limiting the ability for the user to >>> run the graphical installer successfully, consideration on not releasing >>> a distro would be a wise decision. >> Where's the bug for the broken text installer? I'm pretty sure that 'linux >> video=vesa' still works too, to force the vesa driver, which according to the >> reporter does give some gui support. > I filed a bug report and referenced the text installer being out of > sync. I'll files a bug report regarding selecting the customizing > packages via the F2 key shows packages from the group different from the > highlighted main group. I figured that this problem could not have been > overlooked. Someone would report or catch this problem. This was filed and I fixed it up on Tuesday-ish I believe

> An option to help the many users trying to install Fedora with the GUI > would be to have a dialog box to allow selecting the "vesa" driver > instead of having the user search around for the video=vesa parameter > given to the installer. The problem is that for _most_ users, they're going to hit enter on their CD and go straight into graphical mode. Adding a step to configure your video card here is entirely the wrong answer as it can't be done in a way that's internationalized across all of the locales that are to be supported. Not to mention that text mode screens just look ugly to casual users :-)

Post-FC6, I want to look at trying to use some of the more advanced syslinux menu'ing capabilities that are now present so that we can try to do a little more to lead people to things like this from the bootloader. But, as always, it's a matter of tradeoffs and time as to what gets done versus left behind for any given release.

Jeremy

On Thursday 05 October 2006 22:37, Jim Cornette wrote: > I filed a bug report and referenced the text installer being out of > sync. I'll files a bug report regarding selecting the customizing > packages via the F2 key shows packages from the group different from the > highlighted main group. I figured that this problem could not have been > overlooked. Someone would report or catch this problem. This (package groups wrong) has been reported, and I do believe already fixed in CVS, and possibly in the rawhide that hit this afternoon. The stalling issue may very well be due to 256megs~ of ram. We ran into this today as well, we were going to spend some time duplicating and diagnosing tomorrow.

On Thu, 2006-10-05 at 22:12 -0400, Jesse Keating wrote: > On Thursday 05 October 2006 22:03, Jim Cornette wrote: >> With a broken text installer and limiting the ability for the user to >> run the graphical installer successfully, consideration on not releasing >> a distro would be a wise decision. > Where's the bug for the broken text installer? I'm pretty sure that 'linux > video=vesa' still works too, to force the vesa driver, which according to the > reporter does give some gui support. It's 'linux xdriver=vesa'[1] Jeremy [1] Replacing the old 'linux vesa' with a more generic form to be used if you want to switch i810 vs intel or any other switch of the sort.

Just wanted to add that I'm planning to update my G550 machine from FC3 to FC6 some time in November. I hope to be able to run mga driver rather vesa... My point being: there are Fedora users with Matrox graphics cards out there. I'm one of them.

My Matrox cards work fine, so it's sort of hard for me to reproduce the bug, or characterize it sufficiently to provide test drivers. And yeah, normally I don't see bugs in NEEDINFO because I'm the one who put them there and when the user clicks the magic check box they pop back out.

It wouldn't really be acceptable to simply downgrade the driver, since that would lose support for new hardware.

My Matrox cards work fine, so it's sort of hard for me to reproduce the bug, or characterize it sufficiently to provide test drivers.  And yeah, normally I don't see bugs in NEEDINFO because I'm the one who put them there and when the user clicks the magic check box they pop back out.

It wouldn't really be acceptable to simply downgrade the driver, since that would lose support for new hardware.

It's still the wrong time to start complaining however, its one for errata.

On Thu, Oct 05, 2006 at 04:25:12PM -0400, Adam Jackson wrote: > It wouldn't really be acceptable to simply downgrade the driver, since > that would lose support for new hardware If the new driver doesn't work at all then downgrading it doesn't lose support for anything. It's still the wrong time to start complaining however, its one for errata.

https://bugzilla.redhat.com/197033 It has been enough time to downgrade the driver or request more feedback from users who are hit hard by this. But what has happened instead? The "bugzilla > /dev/null" syndrom again. Zero interest in avoiding this serious regression compared with FC5. I'm not impressed. Actually, I'm in really bad mood, and that is the case seldomly. Thanks for listening.