[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
[Xpert]Re: Where Should I Be Sending Patches?
On Tue, 14 May 2002, Dr Andrew C Aitchison wrote: -- From xc/programs/Xserver/hw/xfree86/doc/README: 3.4 Xpert If instead you are the lone developer who is improving XFree86 on an ad hoc basis for your particular environment (I want to get my mouse or video card to work), and need a specific question asked then you should go over to our Xpert list where such questions are raised and answered by our technical development staff. Remember you do not have to be a member to write fixes to our code base and if your changes are discrete and self-contained the volume of developer mail may just be too noisy. Once your work is finished (coded, debugged and documented) please send your fix to [EMAIL PROTECTED]. This will ensure that they are included in future releases. And thanks! You make this truly an Open group. To be truely open, it needs to be viewable/queryable by members of the community, and trackable. -- 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]RE: Where Should I Be Sending Patches?
On Tue, 14 May 2002, Dr Andrew C Aitchison wrote: There are about a handful of people who see these patches, I'm not sure that any of them are paid to work on XFree86, so you are asking a volounteer developer to spend time understanding someone else's patch (including the issues involved) and then do the boring administrative stuff of integrating it. Indeed, and it is understandable that volunteer work can only accomplish so much in a given amount of time. I think the problem is not that patches/fixes don't get integrated instantly, but rather that there is no two way communication mechanism present. An automated system can help with this. I think code cutting is fun, but I wouldn't enjoy integrating patches. I also agree with that. When a bug report comes into bugzilla, once I am looking into the issue, I have the bug number on hand, and have it open in a web browser. Once the fix is applied - either included with the bug report, or whipped up or from elsewhere, I can then make a comment in the report which takes virtually zero time/effort fixed in 4.2.0-9 in rawhide, please reopen if the problem persists or somesuch, and click CLOSED-RAWHIDE or some other resolution that is fitting. The end user receives an email on this, as do any other people who have added themselves to the bug CC list, informing them the issue is resolved. It takes me no more time to do this, than it would to read an email, fix a bug, add a changelog entry. I think the gains it brings far outweigh any /perceived/ disadvantages by far. If I were running a large project on a volunteer basis, I would definitely use bugzilla to manage it, as it saves time, rather than requiring more time. If all projects using bugzilla didn't result in more being done in less time, by those same volunteers they likely wouldn't use it at all IMHO if it just created more work. -- 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]RE: Where Should I Be Sending Patches?
On 14 May 2002, Michel Dänzer wrote: This is all very well, but i sent patches to [EMAIL PROTECTED] nearly 3 weeks ago and i've had nothing back apart from an automatic response! does *ANYONE* read it? There is another list for registered developers to submit patches, and the turn around can be as bad as that, although I would usually expect to see my changes in CVS within 2 weeks. You're lucky. Now that Red Hat 7.3 ships 4.2, I get private mail about a problem in the r128 and radeon drivers for which I submitted a fix (#5199) on March 9th, without any response yet... Bummer, I didn't see that fix, and so didn't apply it to our package. I've just applied it to my development build however. If this was on a public bugzilla tracker on XFree86.org for example, there's more likelyhood of more widespread testing/feedback occuring, as well as those interested in the specific bug being able to opt-in on receiving updates to that bug report, including good/bad feedback from those who have tested it and confirmed it to work, or found it to not work. Distribution maintainers querying for bug reports, could find the issue, the patch, the collaborative bug tracking details from people who have tried the fix, and can communicate among those affected, and other developers working on the issue more readily. As it is now, to find it, you have to be an XFree86.org member, and read every incoming email, hoping not to misplace one, and/or exercise your MUA search feature to hopefully find fixes submitted by others. No multi-way communication mechanism is really present or easily possible. There are about a handful of people who see these patches, I'm not sure that any of them are paid to work on XFree86, so you are asking a volounteer developer to spend time understanding someone else's patch (including the issues involved) and then do the boring administrative stuff of integrating it. I think code cutting is fun, but I wouldn't enjoy integrating patches. There are certainly more interesting things, but I'd be willing to do a share if I get a chance. As would I as time permits. I think the number of I would too's present would be large enough to make it quite beneficial to the project overall. -- 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
RE: [Xpert]Re: Where Should I Be Sending Patches?
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
Re: [Xpert]Re: Where Should I Be Sending Patches?
There are four ingredients for a bug tracking system to succeed, as I see it: 1. Interest and cooperation from the developer community itself 2. The machine resources/network to support the system (available; I know we have a machine here we could use, if no other, so it is a certainty) 3. Good installation and customization of the system to provide good catagorization of bugs (two people have volunteered with this part of the problem, Kurt Wall, and Jeff Waugh (via private mail to me)) 4. Someone (or set of people) to perform bug triage, entering existing bugs initially, and once established, assign initial catagories, mark duplicates, produce statistics as releases near, and eventually cull the database of long fixed bugs. 1) is obviously essential. And 4) is needed to keep the quality up, so that the developers don't go nuts (for example, what happened to the nautilus folks during Gnome 2 development). Many of the major projects have serious resources assigned to the triage/catagorization and maintenance of their bug tracking systems. So 4) is also key (2, and 3 can be considered solved problems, IMHO). 3) is a significant amount of work initially, and only a small amount ongoing: if things aren't set up well (and tuned), then bug reports are hard to deal with and don't go in the right directions. I gather some previous attempts were not well done. I know that Jamey Hicks here spent a number of days working out this catagorization stuff on the handhelds.org bugzilla, so this is not just a one day and your done sort of job. As Mike points out, establishing a transparent system would allow more people to actually help on resolving problems. It is also a way for people to get their feet wet on the project (as they do on some of the other major projects) by taking bugs, working on fixes, and posting patches. Some people even appear to enjoy this sort of work. With the current opaque system, there is no way to enlist people into helping with bug fixing. Some of the most valuable people in some other projects wander around fixing lots, and lots, and lots of bugs. This would help the scaling issue, I think, which XFree86 faces. So the outstanding questions are: 1) are the people who do XFree86 developement interested/willing to work with such a tool? 2) who is willing, if anyone, to become bugmeister and properly deal with the database? This is a significant amount of work; one might argue that the commercial Linux vendors are those with the most to gain by helping out here. I think answers to both in the affirmative are necessary before one goes any further, and unless the answers our yes, we live with the current system until there are credible answers. If this is done, it had better be done well: I gather that previous attempts have failed for various reasons, and I think good answers to all four questions are essential. - Jim -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Where Should I Be Sending Patches?
Hi all, I am not a XFree developer but I'd like to show a user viewpoint: X is faced as something strange, misterious and not transparent. Ex: Check out the rage 128 driver status (the driver of my complaints): Know limitations: none Pardon me , is there an errata for XF 4.2 ? More ? Some time ago I tried in every possible place to obtain a list of Xv capable XFree drivers...Mission Impossible (support is either accelerated or non accelerated), and no one seems to know that. Check out mozilla as an example: I sent dozens of bug reports, and allways was notified by email about their status, and the developers sometimes asked for other trials. Even workarounds get posted there. And well... #xfree86 is silent as a cave...and btw, Mr Mike Harris was one of the few people that was so kind to answer some questions. It really helped. Thanks a lot ! Why do #kde, #mozilla, #xine and others have lot's of non developers hanging and helping people while #xfree86 does not ? Doesn't it mean something ? Now, since X is at least as importante as KDE or Gnome, is X less suported by the distros then those projects ? Keep up the good work (and build a bugzilla :) ) Gustavo ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
