Fri, 09 Nov 2007
Upstream, Upstream, Upstream
When I find a bug in a Linux application, I as a good netizen try to report the bug somewhere (report nothing, expect nothing). A good place for such reports was the Red Hat Bugzilla. People there were the package maintainers who knew where the package was originated from, were subscribed to the appropriate mailing lists, and thus had good means of pushing the fixes to the original developers (aka "upstream"). Apparently, these days are over.
Nowadays, RH/Fedora developers either ignore the reports, and after few months just ping the reporter with "please verify that the bug still exists on an uptodate system, or we will close the bug" (it is real, see here), or they say "not a Fedora bug, please go upstream".
While I do not have a problem with going upstream per se, it is a bit annoying: I have to find out where the upstream is (whether the developers have some mailing list, bug tracking system, IRC channel or what), then subscribe to the mailing list or create the upstream Bugzilla account (which often takes several hours because of the greylisting inbetween), and re-report the problem.
As a minimum level of politeness, I would expect that every "go upstream" suggestion should include the description of where the upstream is. Even better, it would be nice if every package had an "upstream" attribute, where in the machine-parsable form one could find the exact location of upstream Bugzilla, Trac, mailing list or whatever.
9 replies for this story:
Milan Zamazal wrote:
Upstream bug reports are not uncommon in Debian bug tracking system. I must say I don't like users who carelessly report upstream bugs to Debian, because then I serve just as a forwarding service between the user and the upstream maintainers. OTOH it is better to annoy a package maintainer with an upstream bug than upstream maintainers with a package bug (because then they can become annoyed about some distributions and stop to cooperate). Sometimes a package maintainer serves as a filter that protects upstream maintainers from confused or incomplete bug reports. If an upstream project uses Bugzilla with registration, blame the upstream project and not the distribution. I tend not to report bugs to closed places (like a BTS with compulsory registration or a mailing list closed to non-subscribers), I've got better things to do than overcoming obstacles. I completely agree with your conclusion about distribution policies. In Debian, every package must provide information about its upstream source location. And if a user reports an upstream bug I either forward it myself or tell the user where to report it to and then I watch the given place for results. If a distribution doesn't work this way, you should complain. Just don't be too impatient, I think a week is a reasonable time frame to expect initial answer (at least something like "I'm busy now, I'll look at it later").
anicka wrote:
As a SUSE package maintainer I must say that we welcome all the bugreports, even those that will finally end in upstream bugzillas. Why? First, we should help our users. Second, we know where is upstream and we are used to contact them - it will cost us much less time than our users. Third, user can be never sure whether the bug exists also in the upstrem version or only somewhere in a bunch of distro patches, so it is natural to report to the distribution bugzilla and ask the package maintainer to do the rest. It is his work, after all - and as for me, I am trying to do my best to fix the bug and forward to the upstream the fix, not the report. So I think that the response you are describing is a bit shameful and I know that it is possible to make a difference. At least, a good maintainer will spend nearly no time forwarding the reports, he communicates with upstream anyway.
thingie wrote:
Hm. I think I would switch to paid distribution, if someone told me that I have to think if the bug should be filled into upstream bugzilla or the distribution one.
Milan Zamazal wrote:
Why do you think a volunteer should spend his effort on something while you even don't bother to think? If you don't want to make your contribution than indeed you should pay someone for the extra services you want, that's fair (and may be a good way to help). Free software is about cooperation, not about free beer. If a user is unable to identify the source of a bug, it's completely fine to report it to the distribution BTS and this is his positive contribution. But if a user can do more and doesn't do it, he just damages both developers and users by wasting limited resources which could be spent better. BTW, a good package maintainer doesn't just forward upstream bug reports, he should first read it, try to reproduce it, ask the user for more information if needed, etc. And this is often significantly more than "no time".
thingie wrote:
I don't think this is (or should be) extra service. Maybe it is another difference between collection-of-some-packages distributions and real ones :-)
petr_p wrote:
I agree with thingie. Fedora or OpenSuse have an advantage in being sandbox for commercial distros. IMHO, their package maintainers are forced by employer to solve all bugs (including upstream ones) otherwise the same bug would have be fixed by someone else form same company for the commercial twin. I see the complain-to-upstream phenomenon in Gentoo. Here it's extremly easy to incoroporate new patch into package or to resolve if a bug is caused by distributor. However Gentoo developers are to much busy with distro infrastructure and package relations, so they just fix security bugs and commit new upstream releases. It's about minimization of patch set living in distro.
Milan Zamazal wrote:
thingie: Making a distribution is about making packages work together, not about upstream development (although these areas often overlap). petr: Yes, it is often in interest of commercial distributions to provide the extra services and they have paid people to work on it. Non-commercial distributions are more focused on balanced mutual cooperation ("users for users") as users basically don't finance the development and so they are supposed to help in other ways (although money can still make difference, for instance I'm paid for maintenance of some of my Debian packages by a non-profit company, not related to Debian). So different distributions offer different models and it's user's choice and preference to choose among them. Naturally, most users are non-IT types and prefer the "do it for me all and I or someone else will pay for it" model.
thingie wrote:
Yes, distribution is not about upstream development, which takes place in upstream bugzilla. I think that by using upstream bugzilla I would participate on upstream development. Which might be what I want to do for few packages that I know well, but it is not what I want for the rest of packages. Quite often it is hard enough just to find which package contains the bug... It doesn't depend on if I'm a non-IT type or an IT-type. I don't want to participate in upstream development of more than say about 20 packages.
Karel Zak wrote:
The "please verify that the bug still exists.." is definitely not a default Fedora strategy... Some maintainers use it for heavily developed packages (for example kernel). Sometime is cheaper to ask for verification than try to reproduce all bugs.
Reply to this story:
Tue, 06 Nov 2007
XRandR
I have installed Fedora 8 on my
workstation. Everything works as expected, except the multihead support.
I am getting the "Requested Entity already in use!" error message.
The problem is that my xorg.conf uses two separate screens,
instead of one screen merged by XRandR extension (which is
apparently
the preferred way of doing dual-head now).
While not a bad thing per se, XRandR seems to be unusable for my dual head setup: I want the workspace switcher work separately for each head. With XRandR, there is only one big virtual screen area, so the workspace switcher switches both heads at once.
I think XRandR would be useful for my laptop which has 16:10 screen, so the aspect ratio for the external beamer would be different. Also, it could allow to see the lecture notes together with slides when doing a presentation. Here is a little RandR dualhead howto.
My dear lazyweb, does anybody know how to do a multi-screen setup (as opposed to one virtual screen area) in XRandR? For now, I have downgraded to the Fedora 7 version of the ATI driver, which works the way I want. Bug reported as #368531.
4 replies for this story:
thingie wrote:
My WM can switch workspaces separately for each screen, so it is possible to do what you want even with one big virtual desktop across multiple screens. You only need better WM :o)
Yenya wrote: Re: thingie
GNOME workspace switcher also can switch virtual desktops separately for each screen. But with XRandR, you don't have two screens.
thingie wrote:
Screen = one head (physical device). Evil terminology :-)
heycam wrote:
I have the same problem. I found the latest xorg 6.6 broke, and was suggested to upgrade to 6.7 (with RandR 1.2). But that prevents me from doing the two-screens-with-separate-WMs trick to allow me to control workspaces on each independently. thingie, which WM do you have that allows this? (I'm using sawfish.)