Question: easy way to watch new bugs

Sat Mar 8 21:44:28 UTC 2008

Arne Chr. Jorgensen wrote:
> Some ideas:
> 
> How does updates work ?  Are they sent over a separate port ?
> Why not have a bug-report tool on a separate port, not using email ?

Updates are fetched via http or ftp from normal ftp and http servers.  Its a 
well established setup and not anything fancy there.

Email works behind corporate firewalls and in the majority of cases users can 
still get to email one way or another when the machine involved is fairly 
broken.  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.

> 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:

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.

Also, rawhide packages are not signed and have no signature key ID there to use 
for this purpose.

> 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 ) 

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.  All you need to do is open the smolt 
system tool, go to My Smolt Page, and then copy of the link into bz reports.

> 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.

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).

> 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.

Well I think that is an interesting workflow but for me personally I don't see 
it being any faster or simpler than working through a browser really.

>                             -------------------
> 
> 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

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.  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. ;)

-- 
Andrew Farris <lordmorgul at gmail.com> www.lordmorgul.net
  gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----