On Sun, Aug 26, 2007 at 05:36:10PM -0400, Todd Zullinger wrote: > Charles Curley wrote: > Fair enough. > > I sincerely hope I didn't come across as shitting on you for not > reporting it to bugzilla. You didn't. Others in other fora have been less polite. I was reacting to them and took it out on you. Sorry about that. > > "Comrade Zullinger, you haven't written enough lines of free > > software this week. Back to your terminal!" > > Hehe. I try to bail quickly from places that bark orders at me. Good. We need more people who will do that. > > > So if you don't mind, I will determine whether something is "that > > much to ask" of me. > > Nope, I don't mind at all (in fact, I'd prefer that you determine > that). I hope I didn't give the wrong impression in my replies. The > thing that spurred me to write is the part about expecting maintainers > to be subscribed here. That's similar to expecting all users to > report all bugs to bugzilla (perhaps a little worse IMHO, since the > signal to noise ratio here is much lower than it is in bugzilla :). It didn't occur to me that someone who maintained one or more packages for Fedora wouldn't also use it, and so wouldn't be on this list. Really. > > And since there are more users than maintainers here, the side of the > maintainers is in more need of stating now and again. Yup. Which side you are getting to learn. > > > Thanks for the thought. No-one has to do anything on this list, > > except maybe the paid employees whose duties encompass such things. > > Indeed. I'm curious about it now and if other tasks don't fill my > time and distract me, I may well poke into the mantis package a bit. > If it's really fubar'd, it should be fixed or removed. It'd be far > better to have you not find the package than to find it and waste an > hour or more before just installing the tarball. > > I know nothing about mantis though, so I wonder if it could be the > sort of package like mailman, where there is a lot that needs to be > done after installing the package before it will work? If so, there > should be a fedora specific readme somewhere that explains such steps. There is a Fedora specific README which outlines a short process to go through. I followed it, to no avail. (Such documents should be mentioned in the description field of the spec so installers know they exist, but that's another tirade!) > > >> (In the case of the above bug, it's also possible that it was fixed in > >> a newer gnome release and it just didn't get closed properly. > > > > Nope, hasn't been fixed as far as I know. Sorry, I thought that was > > implied when I described the bug as "outstanding" rather than "still > > open". > > I just didn't guess that you were being so specific with your wording > (you damn writers ;). If it's still an issue with new versions, then > the report could be updated to note that it still applies to f7. > Otherwise it may end up getting closed when someone comes along and > auto-closes bugs from older releases*. And changing the release > version along with a comment something like "Ping! This is still a > problem, any news?" may reach Ray at a moment when he can reply or > look into it. (And to be clear, that's just a suggestion, I'm not > saying you need to do this. :) Good point. > > * I do think that if and when such bugs are closed, they generate a > message to the reporter (and others on the CC list) that if they > still apply to a current release, to reopen and change the release. I believe bugzilla sends an email, but don't recall the contents. I have reopened bugs under such circumstances but don't remember if they were in RH's bugzilla or elsewhere. > > > As you say, probably an upstream bug. Given the likely nature of the > > problem, I doubt it's a packaging issue. Speaking of "too much to > > ask", could Mr. Strode enter the upstream issue number or URL and > > mark the bug appropriately? > > Perhaps. It may already be in the gnome bugzilla. It'd just take > someone to search there and tag the rh bugzilla appropriately. Ray > may or may not have time to do that (I don't know him personally.) Ah, I was assuming that if Ray decided it was an upstream bug he'd file in their bugzilla (and search prior to filing, etc.). In that case, he'd know the number. > > I think that generally, if a bug is likely to be an upstream bug (not > a distro-specific or packaging bug), that it should be reported > upstream directly. That way it can be addressed and fixed upstream > for all distros to pick up when an update occurs. Who knows, maybe > the bug you reported has been fixed by another distro maintainer and > no one has yet reported it upstream so we can all get the fix. I had understood that Fedora preferred such bugs to be filed in RH's bugzilla and if necessary the maintainer would file upstream. I don't recall where I got that, and it may have changed since I did. I would think the packager, especially a person who is both maintaining a package and actively contributing to the upstream project, would be in a better position to determine whether to report upstream than an end user. > > > He hasn't even taken ownership, so I have no reason to believe he > > has reported it upstream. > > Sometimes this can be caused by bugs getting reassigned as teams at > RedHat change members. I'm not saying the bug shouldn't get > acknowledged or anything, just offering a possibly reasonable > explanation for why it's gone so long without even being assigned. When someone owning bugs leaves a team, he (or his manager) mass-assigns his bugs to a special management account specifically for the purpose. When someone new comes in or someone else is assigned a package to maintain, management then assigns that person bugs from the special account. Been there, done that. I know there are other ways bugs can slip through the cracks. I've probably committed a few of them myself. Good management processes minimize that sort of thing. -- Charles Curley /"\ ASCII Ribbon Campaign Looking for fine software \ / Respect for open standards and/or writing? X No HTML/RTF in email http://www.charlescurley.com / \ No M$ Word docs in email Key fingerprint = CE5C 6645 A45A 64E4 94C0 809C FFF6 4C48 4ECD DFDB
Attachment:
pgpkFmXoxM4lP.pgp
Description: PGP signature
