So everyone agrees that this is a fabulous idea. Is there a concrete
proposal ready to fall out of it -- something that we can hand to someone
and say "hey, do this"?
Here's what we've already got, and have had for ages:
* the client-side bits that harvest the hardware data. They come from the
up2date/rhn_register client... which is, yaaay! open source. Back in the
day, this code was based on kudzu, and now I guess it's based on lshal.
RHN basically formats this data and sends it via xmlrpc to RHN servers --
where, near as I can tell, it sits uselessly because no one has time to
analyze the data.
Here's what we need to get started:
* A dead simple client. Maybe based on the RHN codebase, maybe not.
Basically: "did your system work like a charm out of the box? Click A.
Not so much? Click B." Format the data, send it up via xmlrpc, all done,
thanks so much.
* A dead simple xmlrpc server in the fp.o infrastructure that pulls this
data and "does something with it". Probably the best thing is just to
shove it into mysql.
* A simple way of reporting on this data and making it visible. Generate
a list of hardware and rank each item with a ratio of "found in good
configurations" versus "found in bad configurations". The items at the
top of the list will likely be the best. The items at the bottom of the
list will likely be the worst.
Really And For True, to get to version 0.1 of this beast is Not Much Work.
What's required is someone who knows a little xmlrpc, a little sql, and
is willing to take ownership of it.
Perhaps this is a good thing to work on at our first-ever Fedora Hackfest,
to be announced Real Soon Now (tm).
--g
On Wed, 22 Nov 2006, Jason L Tibbitts III wrote:
"CB" == Christopher Blizzard <blizzard@xxxxxxxxxx> writes:
CB> If we are able to collect a set of hardware profiles for people,
CB> just after an install, and tie that to a unique machine
CB> identifier, we could make that really useful for people. The
CB> reason being that having access to information about what hardware
CB> people are really using allows us to know where we need to
CB> concentrate our efforts.
I and I'm sure a good portion of Fedora users would happily install
a package that periodically sent various bits of info related to what
hardware is in the system, what packages are installed, what kernel is
currently running, etc. Such information could be immensely useful to
community packagers as a validation that their packages are actually
being used somewhere.
There are all sorts of useful bits of information we could collect,
most of which require that some client be installed. I suggest that
this isn't a problem as long as:
There's only one thing to install, not a collection of random
info-gathering clients.
The client runs from cron and doesn't consume any memory when it's not
running.
It is not installed by default. The installer can ask, sure. "Please
help us improve Fedora! Do you want to install the blahblah client?".
"Yes" should probably not be the default choice. (It could be
installed by default but not enabled by default, but even that is
probably pushing it. It's about the appearance of impropriety.)
The list of information gathered is presented to the user somehow. An
option should be there to provide someone (root?) with a report of
everything sent in when it's sent in if someone really wants to know.
Updates to the package which provide new information-gathering plugins
should not cause those new plugins to be enabled without user
intervention.
That's pretty much all the evil-minimization you can reasonably do.
The question is whether the response rate will be high enough and
whether the responses you get give you a statistically valid sample.
- J<
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
--
-------------------------------------------------------------
Greg DeKoenigsberg || Fedora Project || fedoraproject.org
Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors
-------------------------------------------------------------
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
_______________________________________________
fedora-advisory-board-readonly mailing list
fedora-advisory-board-readonly@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-advisory-board-readonly
