hi, It has taken me 1 day to file 5-6 minor bugzilla entries today. It such a pain that people avoid doing it, at least I have and I still have a bunch of others that should be reported. Not sure I have time or the effort, and I know this is a common problem. Andrew Farris did comment on my proposition. I will answer that, but include my original post first: ---original------------------------------------------------------- Why not have a bug-report tool on a separate port, not using email ? 1. RPM uses a data base for packages, so let say one would encapsulate each package with tags. My favorite editor in bash, is jmacs. I use it as an example: ------------------------------------------------------------------------ Name : joe Relocations: (not relocatable) Version : 3.5 Vendor: Red Hat, Inc. Release : 3.fc7 Build Date: Fri 23 Feb 2007 11:57:51 AM CET Install Date: Wed 05 Mar 2008 03:40:02 PM CET Build Host: hs20-bc1-5.build.redhat.com Group : Applications/Editors Source RPM: joe-3.5-3.fc7.src.rpm Size : 1015971 License: GPL Signature : DSA/SHA1, Fri 18 May 2007 10:11:54 PM CEST, Key ID b44269d04f2a6fd2 Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> URL : http://sourceforge.net/projects/joe-editor/ Summary : An easy to use, modeless text editor Description : Joe is a powerful, easy to use, modeless text editor. It uses the same WordStar keybindings used in Borland's development environment. /etc/joe /etc/joe/charmaps /etc/joe/charmaps/klingon /etc/joe/ftyperc /etc/joe/jicerc.ru /etc/joe/jmacsrc /etc/joe/joerc /etc/joe/jpicorc etc.... -------------------------------------------------------------------------- Now, notice the signature field. Is the Key ID unique ? If not, a tag may be created. The listed files may be indexed as 1,2,3,4...etc. Asume that I encounter a problem - let say an error in charmaps/klingon: A tool, with a simple email window type, where I may include info as you do to bugzilla is at hand. Communicate directly on a a separate port back to site. The message will include: <Key ID b44269d04f2a6fd2> <file number:3> <Descriptive problem:".."> <Linux version: > <Hardware: > <Configuration: > + what ever else one may agree upon. ( Notice the Hardware, as this is very important. I just added some report on an "..MP-BIOS bug: 8254 timer not connected to IO-APIC", something that only appear on my specific hardware. There are endless of problems related to special hardware and platform ) 2. At the other end, Bugzilla - the report will be filed under the Key ID, and so forth. To attempt to make it a bit more clear: - the suggested application don't need a separate database, as it exist at both ends. In many cases you may not need to file much description of the problem. On connect to site, the info regarding the package will be displayed - but you may go ahead and send your hardware profile, the package ID, etc. This will clearly identify how many people encounter the same problem, and the priority to have it fixed. 3. Notice the <Configuration:> field. A user could use the tool to check how others have set up their specific hardware. It is a damn pain to figure out a lot of these things. Example, after a long time, you find this info: "SHMConfig" "true" has to be set in xorg.conf Well, okay - but how/where ?? In this case, I just tag what I want, and import the file. 4. The above example may include a description of "smart" settings in .bashrc and a whole exchange of options that other users have solved, or found valuable.This is actually some of the most difficult things for new users of Linux. So, this exchange could be of great value for everyone. 5. RedHat, Bugzilla, or anyone else will have a count/rating of uses of programs. Developers may also check how their product is received. It will be a feedback as to what problems exist, for example - bugs or errors that none thought of as the program is ported to another platform. 6. At the site end, other fields may be included, as to HOWTO documents, etc. Plus other options to include, or find out how to use. 7. It is voluntary, it is transparent, you know what you install, if you want to participate, etc. Not like Microsoft or others in which you never know what is exchanged under the hood. 8. If this would cause high demands for a site, configs and other info could use bitTorrent schemes, etc. While I would think that the application would be of great value for RedHat and others. ------------------- So what is needed ? With a little help, I could probably write such a thing myself, while I am not a programmer, and most likely not anywhere close to what I suggest. But programs like pirut and Yum exist, and only minor changes may be needed. If you like this idea, please help promote and bring it up for debate and discussion. //ARNE ----- end of original --------------------------------------------------- From Andrew Farris comments, I will add: 1: > The bugzilla interface and bug database will *not* be abandoned by > Fedora and Red Hat I can assure you... and even getting some minor > changes made to accommodate a new tool will not be easy. ;) > They may still keep it. It would be possible to set up an alternativ trial system. If successful, a wrapper could easily transfer it to the ordinary system. 2: > A bug reporting tool that only works when your system is mostly working > is only sometimes useful. If feedback on the bug can only be retrieved > when the user can get X to work for instance, that just will not be > adequate. > Correct, it has to work also in textmode - in fact, a graphical mode is not needed, as it may pop up in an xterm for example. It could also use /var/log or what ever. 3: > If you have smolt enabled and your profile has been sent to the server > you can include your specific UUID with any bug reports, and give the > developers a very detailed view of the hardware involved. > I may have missed out on the purpose of smolt, as I only thought it mostly was used to gather statistics of what people are using. However, what you suggest is too much work, imo - and bugzilla reports mainly lack the needed info, even as they have tried to force you to include some of the info. ( There are so much confusion, as hardware is different ) 4: > Installed packages could be something that smolt collects in the future > I guess, but thats a big increase in the data it would be sending / > storing. A simple textual list of packages installed can be a hundred > kbytes per machine (and you'd want to database and cross-reference > that data some). > This will do the same thing with only a single string of a few bytes. Database and all such is not needed. It will be fast, and you will not need to search for things, as everything is already gathered and, all info is referenced. 5: > The signature field is for a package to be signed as genuinely created > by the Packager, in this case it is signed by the public/private > keypair for Red Hat, Inc being used for Fedora packages (it is signed > by the release engineering team). It is not unique to that package, it > is the ID that indicates which public key should be used to verify the > signature. > Okay, then it is possible to generate a key for this purpose, and include it. In fact, that isn't even needed, as an unique key can be generated from the package name string. My purpose of adding a number system to the files in the package, was simply to reduce the data amount to a minimum. For speed, for little storage space, as nothing more then a string may be transfered, for instance just a cookie, or a dedicated port. 6. The whole idea is based upon a rapid and simple operation. It would not cost the user more trouble then writing a single text line, and issue send. ( I could probably write a small bash script that would handle the whole operation. It's all that simple ) 7. It's a great advantage for anyone at the receiving end, may give a better report then what is currently working today. But the main advantage is the benefits for the user. You may import configurations, tips&tricks, and just as simple find if you have a local problem, or a bug is known, or programs isn't working. 8. No need to start any other application, no need to write anything in many cases. No searching, as the package or program you are working with is by nature directly routed to the correct place. As explained, it can all be exchanged by a cookie, if you like. 9. > If you're really interested in improving the command line bug > reporting abilities I'd suggest looking at how the python-bugzilla > tools can be improved and just focus on that. > I have tried to check it out, but it seem like I need to get approved with a username and password to get it. And I couldn't find out where and how I can get that. My reason for this suggestion, is that bugs exist for years without being fixed. And a lot of the reason is that bugzilla is a real pain, with little benefit for the user. It too ineffective. I have no ambitions, but simply offer this suggestion. It needs to be discussed, as this is up to the community, their thoughts and ideas about it. If enough think it could be useful, we may get it. Add your input and ideas, and perhaps we will get enough to put together a draft, and get some results. //ARNE <hr size=1>Never miss a thing. <a href="http://us.rd.yahoo.com/evt=51438/*http://www.yahoo.com/r/hs"> Make Yahoo your homepage.</a>