While this message will ultimately meet the "requirements" for reporting to this list ("is this a bug"==fedora-list, "here is a proposed patch"==fedora-devel-list, and "here are some rpms to test"==fedora-test-list), I am going to take the opportunity to comment on a couple other items.
First, I can empathize with those posting to this list about bugs rather than fedora-list because the fedora-list has a too low signal-to-noise ratio. The problem described below has been posted to the fedora-list but has received little in comments. Few Red Hat folks seem to read the list (noteable exception is Bill Nottingham) and I cannot blame them due to the S/N ratio.
Second, I have a question concerning bugzilla reports. Many reports appear to stay in a "NEW" status for a very long time (sometimes forever). While some individuals may be away due to circumstances such as vacation, being sick, etc., I would expect that some attention would be paid to these reports. It is frustrating when they appear to be ignored and the bug continues ... like, why bother reporting it when the report is ignored.
Case in point concerns the working of the gnome panel drawers in Fedora Core 1. During the test cycle when I found that drawers were not converting/working, I reported that: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107648 I then found another report (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=104492) and closed mine in its failure.
2. I continued to hope that this would be fixed in FC1 but when it was not, I looked at bugzilla.gnome.org and found that the problem had been found and fixed in cvs (http://bugzilla.gnome.org/show_bug.cgi?id=121072). Now the report in the Red Hat bugzilla had a number of other bugs marked as dups so this was something bother a lot of individuals. The problem had been fixed in cvs around 16 Sep so there was lots of time to get this fixed before FC1. This is frustrating.
3. OK, so was the update simple ... yes. Looking at the update in the gnome cvs, only one file was hit by the update -- button-wedget.c. I created a patch for only button-widget.c which incorporated updates from the gnome cvs -- by the time I got to it, there had been three updates: the drawer fix plus two other patches which did some minor changing of text messages. While the text message updates also hit other modules, to have them only button-widget.c did not appear to cause any problems. I have attached the patch to bugzilla 104492 as a proposed fix.
4. I also built some rpms with the patch and have posted them to anonymous ftp at ftp://czarc.net/pub
The status of the bugzilla report as of today: still marked as new. Frustrating.
maybe we need a fedora-bugs-list? test-list would be for testing bug-fixed/new rpms/packages or whatnot.
I can't see bugs fitting into testing. Reporting bugs/results for new/testing packages fits here, but not new bugs. Bugzilla isnt exactly the best place to discuss the bug either.
Just a thought.
-- Kevin Francis http://denial.loose-screws.com/
Gene C. wrote:
While this message will ultimately meet the "requirements" for reporting to this list ("is this a bug"==fedora-list, "here is a proposed patch"==fedora-devel-list, and "here are some rpms to test"==fedora-test-list), I am going to take the opportunity to comment on a couple other items.
First, I can empathize with those posting to this list about bugs rather than fedora-list because the fedora-list has a too low signal-to-noise ratio. The problem described below has been posted to the fedora-list but has received little in comments. Few Red Hat folks seem to read the list (noteable exception is Bill Nottingham) and I cannot blame them due to the S/N ratio.
Second, I have a question concerning bugzilla reports. Many reports appear to stay in a "NEW" status for a very long time (sometimes forever). While some individuals may be away due to circumstances such as vacation, being sick, etc., I would expect that some attention would be paid to these reports. It is frustrating when they appear to be ignored and the bug continues ... like, why bother reporting it when the report is ignored.
Case in point concerns the working of the gnome panel drawers in Fedora Core
- During the test cycle when I found that drawers were not
converting/working, I reported that: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107648 I then found another report (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=104492) and closed mine in its failure.
- I continued to hope that this would be fixed in FC1 but when it was not, I
looked at bugzilla.gnome.org and found that the problem had been found and fixed in cvs (http://bugzilla.gnome.org/show_bug.cgi?id=121072). Now the report in the Red Hat bugzilla had a number of other bugs marked as dups so this was something bother a lot of individuals. The problem had been fixed in cvs around 16 Sep so there was lots of time to get this fixed before FC1. This is frustrating.
- OK, so was the update simple ... yes. Looking at the update in the gnome
cvs, only one file was hit by the update -- button-wedget.c. I created a patch for only button-widget.c which incorporated updates from the gnome cvs -- by the time I got to it, there had been three updates: the drawer fix plus two other patches which did some minor changing of text messages. While the text message updates also hit other modules, to have them only button-widget.c did not appear to cause any problems. I have attached the patch to bugzilla 104492 as a proposed fix.
- I also built some rpms with the patch and have posted them to anonymous
ftp at ftp://czarc.net/pub
The status of the bugzilla report as of today: still marked as new. Frustrating.
On Thu, 2003-11-13 at 02:56, Kevin Francis wrote:
maybe we need a fedora-bugs-list? test-list would be for testing bug-fixed/new rpms/packages or whatnot.
I can't see bugs fitting into testing. Reporting bugs/results for new/testing packages fits here, but not new bugs. Bugzilla isnt exactly the best place to discuss the bug either.
I think bugzilla is a good place for bugs. In enforces some structure on bug reports. List can become stuffed with messages like "my X is borked". Bugzilla at least weeds out some of the more vague bug reports. If you can figure out bugzilla, you usually can help a developer solve the problem. If the fedora user base grows, there need to be a screen between the developers and the end users.
I meant in a more Subject: #bugid:<status> or something like that. People seem determined to discuss bugs outside bugzilla, even in -list!
I suppose I am out of my depth though.
-- Kevin Francis http://denial.loose-screws.com/
Will Backman wrote:
On Thu, 2003-11-13 at 02:56, Kevin Francis wrote:
maybe we need a fedora-bugs-list? test-list would be for testing bug-fixed/new rpms/packages or whatnot.
I can't see bugs fitting into testing. Reporting bugs/results for new/testing packages fits here, but not new bugs. Bugzilla isnt exactly the best place to discuss the bug either.
I think bugzilla is a good place for bugs. In enforces some structure on bug reports. List can become stuffed with messages like "my X is borked". Bugzilla at least weeds out some of the more vague bug reports. If you can figure out bugzilla, you usually can help a developer solve the problem. If the fedora user base grows, there need to be a screen between the developers and the end users.
-- fedora-test-list mailing list fedora-test-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-test-list
On Wed, 2003-11-12 at 21:00, Gene C. wrote:
While this message will ultimately meet the "requirements" for reporting to this list ("is this a bug"==fedora-list, "here is a proposed patch"==fedora-devel-list, and "here are some rpms to test"==fedora-test-list), I am going to take the opportunity to comment on a couple other items.
First, I can empathize with those posting to this list about bugs rather than fedora-list because the fedora-list has a too low signal-to-noise ratio. The problem described below has been posted to the fedora-list but has received little in comments. Few Red Hat folks seem to read the list (noteable exception is Bill Nottingham) and I cannot blame them due to the S/N ratio.
Second, I have a question concerning bugzilla reports. Many reports appear to stay in a "NEW" status for a very long time (sometimes forever). While some individuals may be away due to circumstances such as vacation, being sick, etc., I would expect that some attention would be paid to these reports. It is frustrating when they appear to be ignored and the bug continues ... like, why bother reporting it when the report is ignored.
I do understand what you're saying, but you have to look at it from our side too. Take gnome bugs for instance, I and three other basically handle all the gnome packages, and together we have many hundred open bugs for them, and furthermore we all work in gnome upstream where there are thousands of bugs in the gnome bugzilla, many that we own, being maintainers for core upstream packages.
Our daily work consists of many things, like following redhat and gnome upstream mailing list discussions (thousands of email a day), replying to bugreports we get in the redhat and gnome bugzillas, helping people on irc, actually spend time trying to track down and fix bugs, working on new features for redhat, working on upstream development gnome features, work on gnome organizational or sysadmin issues, etc.
Now, the balance between these are very tricky, you don't want to spend all your day reading email, but at the same time its important to keep up to speed and reply to peoples problems, to help people, to keep the mailing lists useful, and to keep the projects on track. Its important to fix bugs, since bugs irritate people and make software suck, but at the same time there *has* to be new work on features, rewrites, etc, since these are what really drive software forward (and in many cases help fix the cause of many bugs you otherwise could spend lots of time working around). At the end of the day, a new major feature in the next release might be more important than a bugfix in the current release that only affects a few people.
This balance act is made even harder by the fact that you really can't context switch between these different things often. To write new code you have to have a large chunk of uninterupted time, or things take a lot more time. Even fixing bugs can take quite som time too, so you can't be interrupted by mail/irc all the time.
The way I try to handle this is to make the different schedules (gnome, fedora, rhel) i work under control what focus my work has. So, during the heavy beta period, say test1 to test3 I work mainly on fixing bugs in bugzilla, but as we reach the "deeply frozen" part after the last beta has shipped I target only extremely bad stop-ship bugs (common crashers, really ugly things in the default setup, etc). Much of this is tracked via the shouldfix and mustfix buglists in bugzilla, but I also have a general feel of what is important of the thousands of bugs i'm responsible for in rh/gnome bugzilla.
So, when the release is freezing and eventually shipped I start to ramp up my feature work. We're lucky with our schedules this time, so this means I get some real time to spend in the gnome 2.5 development phase before the 2.6 feature freeze. During this time I spend much less time on bugzilla, I glance over my bugzilla mails, and read a few that seem important, but I don't spend any real time fixing stuff unless its really really bad (security, etc).
No matter what phase i'm in I try to follow the mailing lists, but when in deep coding mode I tend to do so less detailed and not reply as often. However, just reading email takes me several hours a day, so sometimes when coding I don't even do this for a couple of days.
However, just because I don't immedately work on fixing a bug doesn't mean its "ignored". Eventually the feature development phase will end and we'll reach a stabilization phase again. Then I'll start looking seriously at the reports in bugzilla again, and hopefully I can fix a fair share of the important and the easy bugs.
Even if the bug gets fixed upstream after the release, I don't typically spend time doing an updated package. Hundreds of bugs get fixed in gnome every week, and building, testing and pushing out an updated package takes a large chunk of time. I could easily spend all my time doing that, but that would mean I could do no upstream development at all.
This is also the reason that we want people to report bugs upstream, or refile them ourselves. We're not that many, and we own a lot of code, so we can't spend much time on less important issues. But a bug filed upstream goes directly to the person responsible for the application, who hopefully cares a lot about his app, is more focused on it, and knows it better. (Of course, in some cases we're the upstream owner too...)
What it all comes down to is that bugzilla is a tool to help developers manage their work. There is no guarantee that a bug will be fixed when its in bugzilla, thats all depending on how much time the responsible developer has, how he prioritizes his time, etc. However, if the bug is in bugzilla, there is a better chance of the bug being fixed. The bug won't be forgotten, all information about the bug is stored in the same place, other people can report more info in the bug, and its even possible for other people to help fix the bug.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a war-weary day-dreaming matador moving from town to town, helping folk in trouble. She's a tortured tempestuous former first lady married to the Mob. They fight crime!
On Wed, 2003-11-12 at 15:00, Gene C. wrote:
While this message will ultimately meet the "requirements" for reporting to this list ("is this a bug"==fedora-list, "here is a proposed patch"==fedora-devel-list, and "here are some rpms to test"==fedora-test-list), I am going to take the opportunity to comment on a couple other items.
First, I can empathize with those posting to this list about bugs rather than fedora-list because the fedora-list has a too low signal-to-noise ratio. The problem described below has been posted to the fedora-list but has received little in comments. Few Red Hat folks seem to read the list (noteable exception is Bill Nottingham) and I cannot blame them due to the S/N ratio.
Of you have concerns (or better yet, suggestions!) about the development process, those are best brought up on fedora-devel.
Note that "find more time in the day" is not a particularly useful suggestion ;-(.
Yes, this would have been fixed if we had upgraded gnome-panel to 2.4.1 right after it came out on October 14... but since that was after test3, we weren't going to do that without really going through the changes in detail.
In the ideal world, we'd never ship a release with any ShouldFix bugs still open. We certainly don't always achieve that. Perhaps for FC2, some external people can help nag on ShouldFix bugs. It really does help a lot if somebody posts a list of
"Here are 7 ShouldFix bugs where there are outstanding obvious patches"
Second, I have a question concerning bugzilla reports. Many reports appear to stay in a "NEW" status for a very long time (sometimes forever). While some individuals may be away due to circumstances such as vacation, being sick, etc., I would expect that some attention would be paid to these reports. It is frustrating when they appear to be ignored and the bug continues ... like, why bother reporting it when the report is ignored.
And the question is, what? "Why are you guys slacking off on RH bugzilla?" Hours in the day, basically. So we can bring you new and exciting GTK+, Nautilus, D-BUS, whatever features.
I wouldn't obsess about the *state* of a bug; yes, there is a general policy that bugs should be moved to NEW => ASSSIGNED, once they get looked at, but that really doesn't have much to do with when they get fixed.
[ Long saga about panel drawer bug deleted ]
Luckily, fedora policies make it a lot easier to throw gnome-panel-2.4.1 in updates than it's typically been to do a similar thing as a Red Hat Linux errata.
Regards, Owen
(sorry for the late reply)
On Thu, 13 Nov 2003, Owen Taylor wrote:
And the question is, what? "Why are you guys slacking off on RH bugzilla?" Hours in the day, basically. So we can bring you new and exciting GTK+, Nautilus, D-BUS, whatever features.
I wouldn't obsess about the *state* of a bug; yes, there is a general policy that bugs should be moved to NEW => ASSSIGNED,
I guess this would be another good task for non-programmer volunteers:
1) determine, together with the reporter of the bug, how the bug can be reproduced
2) try to reproduce the bug with the latest upstream version of the program ==> if fixed upstream, mark the bugzilla with a request that the Fedora package be updated ==> if the bug is not fixed upstream, forward the bug request to the upstream package maintainers (eg the KDE or Gnome bugzilla)
3) if the bug was sent upstream, check on its status once in a while ... when it is fixed, ask the Fedora package maintainer to upgrade to a newer upstream version ;)
Some "bug sitting" (baby sitting style) could go a long way towards improving the quality of the software ...
On Ma, 2003-11-18 at 02:09, Rik van Riel wrote:
Some "bug sitting" (baby sitting style) could go a long way towards improving the quality of the software ...
Thanks for the advices Rik.
Could a mailing list be setup which gets all bug changes? (like it would be CCed to it) I do have bugzilla reports to see bugs changed in last 7 days, but mailing list would be much easier to follow.
The status of the bugzilla report as of today: still marked as new. Frustrating.
I figure that some of this is due to a lack of leadership structure. The leadership page is still a draft, mentions an advisory and technical committee, but has yet to add members or even describe how members are chosen.
On Thu, 2003-11-13 at 15:25, Will Backman wrote:
The status of the bugzilla report as of today: still marked as new. Frustrating.
I figure that some of this is due to a lack of leadership structure. The leadership page is still a draft, mentions an advisory and technical committee, but has yet to add members or even describe how members are chosen.
I don't quite see how it is related. If we select some form of leadership, how will the bugs I don't have time to fix get fixed?
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's an obese misogynist messiah on the run. She's a mistrustful hip-hop wrestler with a knack for trouble. They fight crime!
On Thu, 2003-11-13 at 10:29, Alexander Larsson wrote:
On Thu, 2003-11-13 at 15:25, Will Backman wrote:
The status of the bugzilla report as of today: still marked as new. Frustrating.
I figure that some of this is due to a lack of leadership structure. The leadership page is still a draft, mentions an advisory and technical committee, but has yet to add members or even describe how members are chosen.
I don't quite see how it is related. If we select some form of leadership, how will the bugs I don't have time to fix get fixed?
While anyone can fix a bug and post an rpm somewhere on the net, many users only want to draw from "sanctioned" repositories. At this point, all the burden is on a few wonderful folks at RedHat to fill those sanctioned repositories. I think this is the problem that RedHat is trying to avoid by making Fedora a community project and also merging with the fedora.us team. Why else merge with fedora.us?
We need a way to spread the load, but at the same time providing quality screens. I assumed that the "Advisory" and "Technical" committees would address those issues, although I may have been reading too much into "the duties, responsibilities, and members of the advisory committee have not been completely decided."
On Thu, 2003-11-13 at 16:49, Will Backman wrote:
On Thu, 2003-11-13 at 10:29, Alexander Larsson wrote:
On Thu, 2003-11-13 at 15:25, Will Backman wrote:
The status of the bugzilla report as of today: still marked as new. Frustrating.
I figure that some of this is due to a lack of leadership structure. The leadership page is still a draft, mentions an advisory and technical committee, but has yet to add members or even describe how members are chosen.
I don't quite see how it is related. If we select some form of leadership, how will the bugs I don't have time to fix get fixed?
While anyone can fix a bug and post an rpm somewhere on the net, many users only want to draw from "sanctioned" repositories. At this point, all the burden is on a few wonderful folks at RedHat to fill those sanctioned repositories. I think this is the problem that RedHat is trying to avoid by making Fedora a community project and also merging with the fedora.us team. Why else merge with fedora.us?
We need a way to spread the load, but at the same time providing quality screens. I assumed that the "Advisory" and "Technical" committees would address those issues, although I may have been reading too much into "the duties, responsibilities, and members of the advisory committee have not been completely decided."
Sure. Given a larger community working on bugfixing etc, and some way to ensure quality of the changes to the codebase things might go faster. But its really not fixing the problem, just making it slighly better. Anyone can fix stuff in upstream Gnome, and any good fixes will be commited to the gnome cvs tree (and many are). But there are still lots of bugs in gnome bugzilla that are not fixed.
The reality is that you just can't rely on a bug filed to be fixed immediately (unless you help fix it yourself). The people working on the distro (be they redhat employees or not) all have their own priorities and limited time.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a suave vegetarian dog-catcher with no name. She's a pregnant snooty museum curator with a birthmark shaped like Liberty's torch. They fight crime!
I figure that some of this is due to a lack of leadership structure. The leadership page is still a draft, mentions an advisory and technical committee, but has yet to add members or even describe how members are chosen.
Some of it is also that the core stuff is mostly Red Hat maintainers. But that doesn't mean you cant do testing and fix bugs. Often upstream is the better place to fix your bug anyway (so all gnome users get it promptly not just RH ones for example)
Fedora.us also needs folks to test/QA the current contributed non core stuff so people can get started. So if there is an app you use and its not critical its perfectly 100% working every day then grab the testing ones and see how they do
I figure that some of this is due to a lack of leadership structure. The leadership page is still a draft, mentions an advisory and technical committee, but has yet to add members or even describe how members are chosen.
Some of it is also that the core stuff is mostly Red Hat maintainers. But that doesn't mean you cant do testing and fix bugs. Often upstream is the better place to fix your bug anyway (so all gnome users get it promptly not just RH ones for example)
Fedora.us also needs folks to test/QA the current contributed non core stuff so people can get started. So if there is an app you use and its not critical its perfectly 100% working every day then grab the testing ones and see how they do
So I guess I'll add to the "community supported" distribution by watching the lists and trying to steer end-user frustration into constructive action. Time to contribute to the FAQ!
that's a good suggestion for people like me - that want to help, but aren't part of anything.
*goes and starts downloading srpms for QA. -- Kevin Francis http://denial.loose-screws.com/
Alan Cox wrote:
I figure that some of this is due to a lack of leadership structure. The leadership page is still a draft, mentions an advisory and technical committee, but has yet to add members or even describe how members are chosen.
Some of it is also that the core stuff is mostly Red Hat maintainers. But that doesn't mean you cant do testing and fix bugs. Often upstream is the better place to fix your bug anyway (so all gnome users get it promptly not just RH ones for example)
Fedora.us also needs folks to test/QA the current contributed non core stuff so people can get started. So if there is an app you use and its not critical its perfectly 100% working every day then grab the testing ones and see how they do
-- fedora-test-list mailing list fedora-test-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-test-list