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@xxxxxxxxx> 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
---- ----
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
