On Sun, 12 Jan 2003, Georgina Economou wrote: >What about areas that come in that are distro specific, does that go to the >distro maintainer of to XFree86?
If a bug is reported, and the reporter indicates they are using FooLinux, if it can be shown that it is easily a FooLinux specific problem, then there are 2 possibilities I can see: 1) The report has no useful purpose in the bug tracker, and could be closed something like: " This appears to be a FooLinux specific problem you are having, which should be reported to FooLinux in their own bugtracker (optional hyperlink to FooLinux's bug tracker). After filing a bug report at FooLinux, please add a link to that report here so that other users searching for bugs can find your link to FooLinux's bug tracker also" Or, if someone just doesn't feel like going to that level of detail, even just a "This is a FooLinux specific problem you're having, and not a generic XFree86 problem. Please report it to them instead." Of course, more friendlier responses are always more beneficial to users. Perhaps canned replies should even be present for people to choose. Another option is: 2) Add distro specific maintainer to CC list or reassign bug to him/her. Presumeably, all people who maintain X at various different distributions and OS's out there, will want to have bugzilla accounts on the XFree86 bug tracking system. They should be carbon copied on bug reports that are known to be distro specific, or that one suspects might be distro specific. I can't speak for other distribution maintainers, but I for one don't want Red Hat specific bugs clogging up a public project bug tracker any more than I want to read distro specific bugs from some other distribution. I doubt anyone else would either. >Is the XFree86 bugzilla now repsonsbile for all distro bugs, Not by a long shot. How could/would they be? >and there are lots? That's a hard question to answer. Some bug reports are simply "packaging" errors, or errors related to packaging defects. Those such issues, are obviously distro specific, and for the case of RHL, I would expect them to get assigned to me (either by someone else who spots it, or by myself noticing it), in which case I would want it moved to our bugzilla and would probably do so myself, and close out the upstream report, crossreferencing it with our database. This is basically what happens with projects like GNOME et al. I believe. Distributions _want_ to know what bugs they have, so they can fix them and make better products for users. To quantify it however is rather difficult. I suppose someone could volunteer a day or so of time to go through a given distro's database and try to fairly quantify such bug reports to get an idea. It'd be a boring job to perform just to get the statistics though. I'm not sure the stats would be all that valuable though. Any public tracker will definitely end up getting distro specific reports. It's the job of distro maintainers, and bug triage people to strip those out of the public database, and either reassign them to the known distro person, or close them out and refer the person to their own distro's tracker. Having a FooLinux specific bug report in a common bug database isn't going to get it fixed for FooLinux users, and isn't going to be useful to anyone else, so FooLinux doesn't benefit at all from such. On a different note however, I've seen a great many bugs get reported to [EMAIL PROTECTED] in the past and in looking at many of them, I see they are reported by Red Hat Linux users. Many such reports do not contain enough information to determine wether or not they are distro specific or not, however percentagewise, I would say most are not, and are common driver problems instead. I respond privately to many of these people however it is a tedious process via email. It is much much simpler via bugzilla, and so often, my response to them is to file their report in Red Hat bugzilla. That way I can at least attempt to do troubleshooting with them in a sane manner that is viewable and trackable by others. In such cases, if a bug turns out to be RHL specific, then obviously, it's mine. If not, then it's whoever-out-there-including-myself gets to fix it first based on their various priorities. With a bugzilla for X, the process is similar but also easier to manage. I'd be getting emails still of incomig reports, but can simply click on the hyperlink, bring it up in central bugzilla, ask a couple of questions, and then perhaps fix it and send in a patch, perhaps say "this is a Red Hat bug" and close it, crosslinking it to our bugzilla, or acknowledge the problem if I can verify it, and whoever down the road, myself included can get to it and fix it, then more people benefit sooner. >How would bugzilla handle issues where the changes came in from >after the merge from the XFree86 CVS? Would it sort out what is >applicable to the tree OR would the bugmen try to fudge it in >and get their distros bug into the tree so it could be supported >first? I'm not sure what you mean here. >I could see how one distro could use bugzilla very well against >another's for slick marketing More conspiracy theories? ;o) A common theme lately. ;o) Anyway, if a bug is distro specific, then IMHO it is rather obvious, and even if some distro was crooked as you seem to suggest, there would be enough other people involved that were not from the crooked distro to kick their ass. Slashdot is a good place to report such violations. >or to remove the work from their own maintainers. Well, either a bug is distro specific, or it is not distro specific. If it is, then we've covered that above. If a bug is NOT distro specific, then it rightfully would have a place in the project bug tracking database. Individual distributions and OS's who care about that bug enough are likely to cross reference it in their own bug tracking databases. Whenever someone, somewhere fixes the given bug, if other distros have crossref'd the bug, will be made aware of the fix. So, if Debian fixes a bug that 3 other distros are also monitoring, they would be made aware of it by bugzilla, and all distributions, including the main project benefit. If the core XFree86 team fixes the bug, then the same would apply. Whoever fixes an issue (assuming it gets fixed) is not really IMHO relevant, as much as everyone who cares about the bug being notified that it is fixed. Of course, this assumes that the project wants to know about all of the bugs people find in the project's software - regardless of what OS and distribution they are using, so long as it is not a distro specific bug. If the project members do actually use the database, they - like always, have their own free mind to determine what - if any - bugs they will look at, and/or fix. Again, since nobody has the ability to point a gun to someone elses head, I cant visualize the reality of this hypothetical problem put forth above being something realistically viable. If it were a viable thing, I'm sure that GNOME, Mozilla, or one of the other major projects that that use bug trackers would have experienced this type of phenomenon already. Since members of many different open source projects are reading this email, if any of them are aware of any such activity ever occuring as suggested above, I'm sure they'll step forward and offer examples of any single company or vendor trying to abuse a public bug tracking database for their own corporate gain. To be honest, I don't see how it is possible. A bug is either distro specific, in which case reporting it upstream is useless as the distro will never benefit from seeing a fix, or it is not distro specific, in which case other distros benefit from knowing about the bug in a central location, as does the XFree86 project itself. More eyes see the bug, and with duplicates, statistics of how widespread the problem is across all users out there and not just of one distro, whomever fixes the issue, or attempts to do so, goes in with a larger pool of knowledge than they would otherwise. There isn't any pressure on ANYONE to fix anything really because after all, it's all voluntary. >I would think these questions, and others, need to be answered >upfront for a serious undertaking to be made. I think it is perfectly reasonable to ask questions on this topic. If such concerns and fears are indeed valid concerns and fears of people involved then they do indeed need to be discussed. TTYL -- Mike A. Harris _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
