I though i should point out that you already have a volunteer to set up a bug database: Kurt Wall ( see http://www.xfree86.org/pipermail/xpert/2002-May/017211.html ).
Yours, Rob Taylor > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf > Of Mike A. Harris > Sent: Wednesday, May 15, 2002 5:16 PM > To: [EMAIL PROTECTED] > Cc: Owen Taylor; [EMAIL PROTECTED] > Subject: [Xpert]Re: Where Should I Be Sending Patches? > > > On Tue, 14 May 2002, Owen Taylor wrote: > > >> Be patient. > >> > >> We're all busy with other things, and there are plenty of patches still > >> waiting in the queue. Please don't resend anything. > > > >Can I suggest, as a long term goal, having a publically viewable bug > >tracker / patch queue? > > > >At least from my point of view, the current system isn't working very > >well. > > > >If I find a bug in XFree86 (say, > >http://bugzilla.gnome.org/show_bug.cgi?id=81783, which turned up 5 > >minutes ago :-), it's frequently not clear how to proceed. > > > >Yes, I can send mail to [EMAIL PROTECTED] or [EMAIL PROTECTED]; b > >bug report. But in either case it feel like a complete shot in the > >dark. > > > > - I can't check on the status of my bug-report/patch. > > > > - I can't give someone else an URL to go to check on the the status. > > > > - I can't meaningfully give updates ... sending mail to "[EMAIL PROTECTED]" > > saying "you know the patch I sent 2 months ago. Forget it, it turns > > out to have been faulty hardware" at least seems like it won't > > work very well. > > > > - There isn't any reliable way of telling if/when my bug has been applied. > > > > - If the person dealing with the bug report / patch wants to get > > further information, they have communicate with me privately, > > and > > > >I understand very well that something like bugzilla is considerable > >amount of sysadmin work to set up and maintain that would take away > >from someone's hacking. And there simply may not be the resources > >currently. > > > >But for GTK+ and GNOME, we find it an extremely valuable tool to have this > >stuff public ... not a panacea ... I still get plenty of people > >annoyed at me for slow response to GTK+ patches, but at least they see > >a milestone for the bug, and know it hasn't been lost. > > I agree completely. We (Red Hat) receive a lot of bug reports > against XFree86, many of which we just do not have the manpower > to fix/look into, other distributions no doubt have the same > problem. I think a lot of these problems end up falling between > the cracks. > > What makes things a bit worse, is that a bug reported to a distro > vendor that ends up getting fixed by that vendor, generally gets > fixed in that one distribution at that point in time, and doesn't > necessarily propagate to other vendors, or back to XFree86.org in > a timely manner, or at all. Without pointing any fingers at > anyone, some vendors are great with submitting patches back to > XFree86 while others don't bother it seems IMHO. This puts more > work on each distro vendor, to harvest patches from the other > vendors packages also. > > When submitting a patch upstream, you sometimes do get immediate > feedback on a particular patch, and sometimes do not. I never > quite know if a patch I've submitted for example is applied, if > the problem was fixed in a different way, or is still in > someone's queue. > > I fully realize that everyone receiving the patches have full > time jobs themselves, and don't have time to respond to the > number of patches right away or apply them, since this is often > the case for myself as well. > > The problem is though, that bugfixing/patching seems to not scale > well at all. I've submitted 40-45 patches about a week ago or > so, and I've had some feedback from a few core team members about > a few of the patches, which was greatly appreciated. Many of the > other patches I presume are in a main queue, or have been taken > and put in personal patch queues of a given developer to look at > in the future when they're working on that area of code and/or > have time, etc. At least that is probably what I would do if I > was receiving the patches this way. > > When a patch does eventually get applied though, one has to hope > to catch it in a changelog message. I read changelogs and am on > the CVS commits mailing list, however I'm sure many others are > not, and would just appreciate knowing in a simple manner that > their patch was applied or not, and if rejected, perhaps a > reason. > > In the past I've experimented with submitting patches a bit, and > I've found that submitting patches in an ongoing fashion as they > are made, tends to not get them applied sooner unless it is a > rather important issue with a straightforward fix. For our 7.3 > development cycle I decided to submit the whole storm of patches > all at once to save myself some work as I figured the bulk of the > patches I was submitting, most likely would only be applied to > the head of CVS, and probably only just before 4.3.0 was > released. Submitting them in one shot was much less work than > submitting them one at a time, possibly having to bugfix the > patch and resubmit a few times, etc. when there was good chances > they'd queue up until 4.3.0 was near. > > On the #xfree86 channel on irc.openprojects.net, I often point > people to the [EMAIL PROTECTED] bug report list, or the current > XFree86 web based bug submitter CGI. > > People who have sent a few reports there in the past have come > back to me saying "Why should I bother reporting there? I never > get a response back anyway." I generally tell them that > XFree86.org doesn't have the resources to respond to every bug > report right away, or at all in many cases, and that they should > watch the Changelog for their bug to get fixed, as this allows > developers to spend more time fixing bugs, and doing work on X > than emailing people. Generally though, people tend to not care > about that, they just expect to get an acknowledgment, and they > seem discouraged when they don't get it. I get this sometimes > even _with_ bugzilla. So I understand the difficulty involved > with responding to every single bug report. > > The problem with our bugzilla though, is that we do not have > expertise in all of the areas bugs are reported. Also, we do not > support every tiny piece of XFree86 100%, so many issues reported > are considered by us to be low priority and/or WONTFIX. In these > cases, I recommend to people to report the bug upstream to > [EMAIL PROTECTED] and/or [EMAIL PROTECTED] in hopes the > maintainer will fix it, or at least that more people who could > potentially fix the bug are looking at it. > > Since I am also on the receiving end of XFree86 bug reports (via > our bugzilla, with emails sent to me upon new bug report > submissions and updates), I know the volume of incoming reports > can be a bit staggering, and that many are bogus and/or user > misconfiguraton issues, or people just looking for free-ride tech > support. > > However, for both bug reports, and for patches/fixes, I strongly > feel that the administrative overhead that bugzilla would require > would be small compared to the service that it provides, the > patches it harvests into one common place, and to the two-way > communication mechanism it would establish between X users, the > XFree86 core team, and other XFree86 developers like myself. > > Red Hat used to deal with bug reports via email a long time ago > as well. The problem with it was that it was not scalable, it > did not allow a good two-way communication between bug reporter > and bug fixer(s), and it did not allow for bug tracking, > co-ordination, or allow for searching for already reported bugs, > and their solutions/workarounds. Also, the details of a user's > given bug report could easily be lost in email, or forgotten > entirely. Developers can't keep track easily of what issues are > being worked on by other developers. > > Bugzilla IMHO would allow more people who are not on the core > team to be aware of more of the bugs that are being reported, and > would result in more people fixing more bugs. People often come > to me and express an interest in working on X, but don't know > where to start or what to work on. I refer them to our bugzilla, > as there isn't a way they can find out about bugs at XFree86.org > currently. Some tell me "I don't use Red Hat", somehow thinking > that all XFree86 bugs in our bugzilla are specific to Red Hat > Linux, others not wanting to "contribute code that does Red Hat's > job for them" like somehow fixing every bug reported is "our > job". I would much rather be able to point people at a central > bugzilla tracker on XFree86.org, and to be able to consolidate > non-distribution specific bug reports in one place, which will > remove some level of duplication among all distributions, and > including the core team itself. > > This topic has come up before on private XFree86 mailing lists, > and I've also discussed it a bit with Keith Packard (whom I've > added to the CC) and Jim Gettys. Keith set up bugzilla a while > back to investigate it, and I've poked around a bit locally with > it as well. I dunno how far he's gotten with it, but I havn't > had much time to dig into it, and I presume he hasn't either. > > Almost all major projects out there (Mozilla, GNOME, KDE, etc.) > have a web based bug tracker, and most of the larger projects use > bugzilla for the large number of features that it has that cater > to large projects like XFree86. I think XFree86 really needs a > bugzilla bug tracker in order to harvest the wealth of developers > that are out there that currently see X as a black art, or a > mysterious voodoo tarball. > > Lets make XFree86 development, and bug fixing more scalable, and > pool the community of developers and users together. Lets work > together to put up a bugzilla bug tracker on XFree86.org and use > it as the primary tracker of bug reports. I think that would > benefit everyone, and most importantly the end user. > > TTYL > > > -- > Mike A. Harris Shipping/mailing address: > OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, > XFree86 maintainer Ontario, Canada, P6C 5B3 > Red Hat Inc. > http://www.redhat.com ftp://people.redhat.com/mharris > > _______________________________________________ > Xpert mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/xpert > _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
