Hi all,
I've been thinking for a while about how we (the community) could help making Core better, since Core is the foundation on which we all build and since @redhat people can only do so much, I believe it is vital that we as the community get involved in helping Core.
Helping Core can be done in many ways, many of which require infrastructural support. I don't want to talk about those, infrastructure and procedural discussions is not my thing. I'm more of a show me the code type.
As such I would like to build a list with everyone's favorite / pet peeve bugs, or iow the bugs which annoy you the most. Preferably bugs which impact a wider audience then just you and which are fixable by mere mortals like myself :). Now the first question would be where to store this list, please post your comments to this list for now. And to any wikie maintainers reading this, I think this needs a wiki page, agreed?
So everyone please post your bugs here, here are mine:
* I've already mailed todo about the not autoloading of joydev.ko bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187005 And after sinking my teeth into this, a fix has now been reported in BZ, and hopefully should show up in a kernel near you soon :)
* Another bug which has been annoying me is the fact that gnome will no longer start 3 xterms when I login even though xterm is listed 3 times in the non sm programs to start list, appearantly someone thought it would be smart to filter duplicates out of this list :| see: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185114
I've got a pretty good idea how to fix this one (for me atleast) the sorting dups might be a good idea, but if the dups have different arguments then they really aren't dups imho, which would fix this for me. Anyone want to beat me writing a patch for this? (I've got other priorities atm).
Regards,
Hans
On Fri, Aug 04, 2006 at 03:39:36PM +0200, Hans de Goede wrote:
store this list, please post your comments to this list for now. And to any wikie maintainers reading this, I think this needs a wiki page, agreed?
Or a bugzilla keyword.
Matthew Miller wrote:
On Fri, Aug 04, 2006 at 03:39:36PM +0200, Hans de Goede wrote:
store this list, please post your comments to this list for now. And to any wikie maintainers reading this, I think this needs a wiki page, agreed?
Or a bugzilla keyword.
That might be a good idea, or a blocker bug. How do we make sure that not too many or too obscure bugs get set to this keyword / blockerbug? Just remove abusing bugs?
Regards,
Hans
On Fri, Aug 04, 2006 at 07:00:29PM +0200, Hans de Goede wrote:
Or a bugzilla keyword.
That might be a good idea, or a blocker bug. How do we make sure that not too many or too obscure bugs get set to this keyword / blockerbug? Just remove abusing bugs?
Yeah, although we'd have to carefully pick the keyword so as to not offend someone if *their* pet peeve bug got removed.
Perhaps have a way to *nominate* a bug for addition, and only add one after a certain amount of interest?
Matthew Miller wrote:
On Fri, Aug 04, 2006 at 07:00:29PM +0200, Hans de Goede wrote:
Or a bugzilla keyword.
That might be a good idea, or a blocker bug. How do we make sure that not too many or too obscure bugs get set to this keyword / blockerbug? Just remove abusing bugs?
Yeah, although we'd have to carefully pick the keyword so as to not offend someone if *their* pet peeve bug got removed.
I must say I'm more in favor of a blocker bug (since I'm unfamiliar with the use of keywords)
Perhaps have a way to *nominate* a bug for addition, and only add one after a certain amount of interest?
Hmm, I think we should first come up with a tracking mechanism for bugs like this, see how it works and only create procedures surrounding this tracking mechanism if they are needed.
Regards,
Hans
On Fri, Aug 04, 2006 at 07:31:53PM +0200, Hans de Goede wrote:
That might be a good idea, or a blocker bug. How do we make sure that not too many or too obscure bugs get set to this keyword / blockerbug? Just remove abusing bugs?
Yeah, although we'd have to carefully pick the keyword so as to not offend someone if *their* pet peeve bug got removed.
I must say I'm more in favor of a blocker bug (since I'm unfamiliar with the use of keywords)
I'm not sure a blocker bug is really appropriate, as by definition it's unlikely all the dependencies will ever be resolved.
Keywords are really trivial.
Matthew Miller wrote:
On Fri, Aug 04, 2006 at 07:31:53PM +0200, Hans de Goede wrote:
That might be a good idea, or a blocker bug. How do we make sure that not too many or too obscure bugs get set to this keyword / blockerbug? Just remove abusing bugs?
Yeah, although we'd have to carefully pick the keyword so as to not offend someone if *their* pet peeve bug got removed.
I must say I'm more in favor of a blocker bug (since I'm unfamiliar with the use of keywords)
I'm not sure a blocker bug is really appropriate, as by definition it's unlikely all the dependencies will ever be resolved.
The same goes for the FE review tracker bugs, but those are blocker bugs and work well.
Regards,
Hans
Dnia 04-08-2006, pią o godzinie 15:39 +0200, Hans de Goede napisał(a):
bugs which impact a wider audience then just you and which are fixable by mere mortals like myself :)
From my bugs list, there are three really simple to fix issues, but I have to fix them on every new install and every package update (so they're my pet peeves) and there are working patches attached:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186961 (UTF-8 not really working - this is a really wide audience if you use non-curses/readline programs)
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188079 (mc on non-UTF-8 terminals - many people are forced to use 8 bit encodings because so many applications don't support recoding of old data)
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190990 (gnome-terminal not treating ^- as ^_ - the audience may not be so wide in this case :))
Let me repeat that there are working patches attached which may not be best to do the job, but work for few people already.
Lam
Leszek Matok wrote:
Dnia 04-08-2006, pią o godzinie 15:39 +0200, Hans de Goede napisał(a):
bugs which impact a wider audience then just you and which are fixable by mere mortals like myself :)
From my bugs list, there are three really simple to fix issues, but I have to fix them on every new install and every package update (so they're my pet peeves) and there are working patches attached:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186961 (UTF-8 not really working - this is a really wide audience if you use non-curses/readline programs)
Hmm, strange that one hasn't been fixed yet. Maybe ping Bill in the BZ?
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188079 (mc on non-UTF-8 terminals - many people are forced to use 8 bit encodings because so many applications don't support recoding of old data)
I've read it and I think that jnovy will be more then accept a pathc fixing the full problem, sofat there only seem to be some hacks around the problem.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190990 (gnome-terminal not treating ^- as ^_ - the audience may not be so wide in this case :))
I'm not sure if I would call this a bug, see the comment I added.
Regards,
Hans
Hans de Goede napsal(a):
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186961 (UTF-8 not really working - this is a really wide audience if you use non-curses/readline programs)
Hmm, strange that one hasn't been fixed yet. Maybe ping Bill in the BZ?
This is on my short-term list to look at. Mirek
On Fri, Aug 04, 2006 at 07:35:54PM +0200, Hans de Goede wrote:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186961 (UTF-8 not really working - this is a really wide audience if you use non-curses/readline programs)
Yeah X keyboard compose is broken for UK keyboards too so its doubly a pain in the butt 8). And ^[[c doesn't reset the alt charset on a gnome terminal which is PITA and I believe incorrect compared to my real VT terminak.
Some of the non X UTF-8 problems are kernel side. Notably some of the multichar handling stuff. I've asked Andrew to test out a patch someone submitted using -mm.
Yesterday Leszek Matok said:
From my bugs list, there are three really simple to fix issues, but I have to fix them on every new install and every package update (so they're my pet peeves) and there are working patches attached:
+1*2 And a couple more old peeves...
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187268
postfix: permissions on TLS_LICENSE should be 0644, not 0755
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168660
anaconda: Software Raid Mirror wont boot from second disk
The first is the easiest of specfile fixes. No clue why the bug has languished so long. That second peeve might be a bit more tricky. Can anaconda still not tell when the grub MBR belongs on *all* members of a RAID1 mirror?
../C
Hi all,
A bit offtopic for this thread, but since I started it I thought you should now that I'll be on a short vacation starting tomorrow, I'll be back coming wednesday. In the mean time feel free to keep discussing this and to mention any of your pet peeve bugs :)
Maybe we could set up a community pet peeve bugs fighting group the league against pet peeve bugs or lappb :)
Regards,
Hans
Hans de Goede j.w.r.degoede@hhs.nl writes:
Hi all,
I've been thinking for a while about how we (the community) could help making Core better, since Core is the foundation on which we all build and since @redhat people can only do so much, I believe it is vital that we as the community get involved in helping Core.
Helping Core can be done in many ways, many of which require infrastructural support. I don't want to talk about those, infrastructure and procedural discussions is not my thing. I'm more of a show me the code type.
As such I would like to build a list with everyone's favorite / pet peeve bugs, or iow the bugs which annoy you the most. Preferably bugs which impact a wider audience then just you and which are fixable by mere mortals like myself :). Now the first question would be where to store this list, please post your comments to this list for now. And to any wikie maintainers reading this, I think this needs a wiki page, agreed?
So everyone please post your bugs here, here are mine:
- I've already mailed todo about the not autoloading of joydev.ko bug:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187005 And after sinking my teeth into this, a fix has now been reported in BZ, and hopefully should show up in a kernel near you soon :)
- Another bug which has been annoying me is the fact that gnome will no
longer start 3 xterms when I login even though xterm is listed 3 times in the non sm programs to start list, appearantly someone thought it would be smart to filter duplicates out of this list :| see: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185114
I've got a pretty good idea how to fix this one (for me atleast) the sorting dups might be a good idea, but if the dups have different arguments then they really aren't dups imho, which would fix this for me. Anyone want to beat me writing a patch for this? (I've got other priorities atm).
Regards,
Hans
Here is one. It is more a gnome bug but I'll post here for discussion.
* Desktop accommodate much less icons than XP.
With a screen resolution 1280x800, in gnome the desktop can only contain 72 icons while in Windows XP it can do 170 icons i.e XP is 2.36 times as efficient as gnome in using desktop real estate.
The situation in gnome becomes much worse when you have icons with long title. This bug has been filed over 4 years ago. I currently have 46 icons on my desktop and they have taken 7/8 of the desktop.
I think this compromises user's productivity.
On Fri, Aug 04, 2006 at 07:38:17PM +0100, Leon wrote:
- Desktop accommodate much less icons than XP.
With a screen resolution 1280x800, in gnome the desktop can only contain 72 icons while in Windows XP it can do 170 icons i.e XP is 2.36 times as efficient as gnome in using desktop real estate.
Um, yeah, I think that's a feature. :)
But anyway, you can also address it -- go to the Preferences dialog in any Nautilus window and change the default zoom level.
Matthew Miller mattdm@mattdm.org writes:
On Fri, Aug 04, 2006 at 07:38:17PM +0100, Leon wrote:
- Desktop accommodate much less icons than XP.
With a screen resolution 1280x800, in gnome the desktop can only contain 72 icons while in Windows XP it can do 170 icons i.e XP is 2.36 times as efficient as gnome in using desktop real estate.
Um, yeah, I think that's a feature. :)
But anyway, you can also address it -- go to the Preferences dialog in any Nautilus window and change the default zoom level.
OK. Setting the zoom level to 75% reduce the gap between gnome and XP. Now only the long title annoyance remains.
-- Matthew Miller mattdm@mattdm.org http://mattdm.org/ Boston University Linux ------> http://linux.bu.edu/
On Fri, 04 Aug 2006 15:39:36 +0200, Hans de Goede j.w.r.degoede@hhs.nl wrote:
- I've already mailed todo about the not autoloading of joydev.ko bug:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187005 And after sinking my teeth into this, a fix has now been reported in BZ, and hopefully should show up in a kernel near you soon :)
Good work! Are you going to send this upstream yourself or do you need any help?
-- Pete
My pet peeve is the lack of a text input area in the standard file requestor.
All I want to do is to paste a file path from a shell window to get an attachment added to a mail item. Navigating the graphical file requestor to the file is incredibly painful over a slow X-remote session.
I think I reported this as a bug once, and response was that there is a control-key sequence that will pop up a textbox file requestor, but this has two serious problems: - The graphical requestor doesn't remind you what the magical key sequence is. - Popping up yet-another window on a slow X-remote session just aggravates the problem.
If the curent wisdon is that text input of filenames will confuse the target Fedora user, then don't make it default. Just provide me with a configuration option so that I get a text input area in all my file-requestors.
John
On 8/5/06, John Ellson ellson@research.att.com wrote:
All I want to do is to paste a file path from a shell window to get an attachment added to a mail item. Navigating the graphical file requestor to the file is incredibly painful over a slow X-remote session.
I don't think there would be any opposition to detecting paste events on the file selector and opening the text input with the pasted path. You should file a bug about it (be as civil as possible -- the GNOME devs probably won't appreciate another 'file selector sucks' report).
Btw, the '/' key is what is usually used to open the text input - it's not too hard to use.
n0dalus.
On Fri, 2006-08-04 at 19:06 -0400, John Ellson wrote:
My pet peeve is the lack of a text input area in the standard file requestor.
All I want to do is to paste a file path from a shell window to get an attachment added to a mail item. Navigating the graphical file requestor to the file is incredibly painful over a slow X-remote session.
Yeah the GNOME fileselector is really irritating about this. With the stock GTK one, you could navigate through the filesystem, with tab expansion, just like in bash! The GNOME fileselector seems to have killed this functionality.
And the whole row-of-buttons for each directory UI thing on top is a bizzare abuse of buttons. Why can't it just be a text box?
Callum Lerwick wrote:
And the whole row-of-buttons for each directory UI thing on top is a bizzare abuse of buttons. Why can't it just be a text box?
I *so* wish there was a preference (like the one in Nautilus) to switch the behaviour to the text entry bar by default instead of the buttons, by all means have buttons as default if the developers are convinced users like them, but please let me choose to override the default!
On Sat, 2006-08-05 at 22:36 +0100, Andy Burns wrote:
Callum Lerwick wrote:
And the whole row-of-buttons for each directory UI thing on top is a bizzare abuse of buttons. Why can't it just be a text box?
I *so* wish there was a preference (like the one in Nautilus) to switch the behaviour to the text entry bar by default instead of the buttons, by all means have buttons as default if the developers are convinced users like them, but please let me choose to override the default!
Have people actually tried the file selector changes[1] in GTK+ 2.10 (... in test1 and rawhide :)
Jeremy
[1] http://primates.ximian.com/~federico/news-2006-03.html#29
Jeremy Katz wrote:
Have people actually tried the file selector changes[1] in GTK+ 2.10 (... in test1 and rawhide :)
yes, but I'd prefer text entry *instead* of the buttons, and I'd prefer to set text entry as the *default* Perhaps I should do as Federico suggests and get off my ass ...
Andy Burns wrote:
Jeremy Katz wrote:
Have people actually tried the file selector changes[1] in GTK+ 2.10 (... in test1 and rawhide :)
yes, but I'd prefer text entry *instead* of the buttons, and I'd prefer to set text entry as the *default* Perhaps I should do as Federico suggests and get off my ass ...
+1
Having to click on a button to get the text area causes another window repaint which is painful over a slow X-remote connection.
At least one of my pet peeve bugs was recently fixed:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188294
This one, dating back to 2003 remains:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=106552 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131428
Though someone seems to have posted a non-unified diff...
Hans de Goede wrote:
So everyone please post your bugs here
Here's mine https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177823
I logged this against FC5T1 and it still persists in FC6T2, it has been tagged as EASYFIX + REGRESSION and has 25 people who've cc:'ed themselves on the bug ...
-
Alan Cox -
Andy Burns -
Callum Lerwick -
Curtis Doty -
Hans de Goede -
Jeremy Katz -
John Ellson -
Leo -
Leszek Matok -
Matthew Miller -
Miloslav Trmač -
n0dalus -
Pete Zaitcev