issues list(s)

[Benjamin Smith]

On Monday 06 February 2006 15:17, Jesse Keating wrote:
> Just installing the package is not enough.  I could do that myself on
> the build server and call it good.  The package actually needs to be
> used and that requires human interaction.

Jesse, 

I have a Fedora Core 1 server that I use fairly heavily, and I've set up the 
yum repos to include updates-testing, so that testing RPMs get installed 
anytime I update with yum. 

I've had zero performance/reliability issues since doing so in the past 6-9 
months, (THANKS GUYS!) and I figured it might be worthwhile to report this 
fact. Except: 

1) What testing packages are installed that you'd even care about? 
2) What changes should I test for?
3) Looks good, how do I report it? 

So, I wrote a script to at least tell me what packages were officially 
"testing" and which were released. And, it seems to me that it's a fairly 
trivial step from there to take that output, and automate the feedback 
delivery step, if there's some kind of HTTP URI I can interface with to get 
the results to you. 

Otherwise, trying to tell the difference between 

XFree86-ISO8859-2-75dpi-fonts-4.3.0-59.1.legacy.i386.rpm
XFree86-ISO8859-2-75dpi-fonts-4.3.0-59.2.legacy.i386.rpm

out of potentially hundreds of packages is enough to bugger my eyes out, 
especially when, for some packages (EG: Kernel) I may have several installed. 

All I'm asking for is a framework for making it easier for somebody to help 
you out. 

Once you know what testing packages have been installed, an `rpm -ql *rpm` 
would tell what commands have been updated, and it might make sense to parse 
the results of the `history` command, and ask for feedback on logout. Or, 
maybe it'd be better to keep a sqlite database of files and fileatimes, and 
if they change in a login session, ask about it. 

I dunno. All I know is that I work all day long in my day job trying to gather 
information from clients, and have long ago learned to make such information 
gathering as stupid simple as possible, or it just won't happen. 

As it is, I spent some time trying to figure out WTF to do and where, and got 
frustrated. Perhaps this sounds dumb, and maybe you don't want my input, but 
rule #1 for volunteers is to make it easy to do the "right thing", and as a 
volunteer, I'd like to make this possible. 

I encourage you to look in the archives for my little PHP script that solves 
question #1 above, I'd like to take this (or the perl script volunteered by 
somebody else) and put together something that hopefully makes reporting 
success/failure a little more straightforward. If you want, I'll find it and 
resend. 

-Ben 
-- 
"The best way to predict the future is to invent it."
- XEROX PARC slogan, circa 1978