Oke, sounds all very interesting but i would like to know a few
Like I say, I hadn't thought about this as a GSoC project before so none
of my answers are set in stone:
Lets assume WebUI is the one that is gonna be developed for a moment
(otherwise fill in the name you want).
1. Will the WebUI be able to contact the koji package database?
I hadn't thought so but we could talk to the koji authors about it.
I've heard two thoughts on access to koji's db at different times:
1) koji is one possible front-end to koji db. Other front ends could
2) koji db should only be accessed through koji's xmlrpc calls.
I'm not sure which of these two is the current answer. We'd need to
talk to mbonnet and mikem about which they prefer.
2. What is the preferred language to write this in? php? java? python
Must be python. I'm very heavily in favor of it being a feature of
either the pkgdb or myfedora. I think it makes more sense of it being a
part of pkgdb and then myfedora can import it to one of its tabs (as
it's currently doing with other pkgdb, koji, bodhi pages).
3. Is is gonna be a part of fedora (hosted on the fedora place) or
it all just community work that fedora will initialize but than pulls
it hands of?
Part of Fedora.
I'm asking those things because i'm interested in this as
letting WebUI work with Koji's package database seems like a perfect
solution to me because all the packages for fedora are in there
already so all you have to do then is make it possible in the koji
database to fetch distribution specific rpm's (so for F7 only, F8
only, Rawhide only or all and i'm sure (i hope) the current database
of koji can already do this (tags)).
The other option is to get this information from the yum repodata. This
lacks historical information (it's only information in the present
repository) but that may be the way to go for several reasons:
* We've had issues with kojidb failing to scale under the load that koji
can place on it (we'll be getting a database server dedicated to koji at
some point which may alleviate this but that's both speculative and
something for the future.)
* repodata will show what's available to yum for downloading which is
synced with what an end-user will see.
And last question. How do you need to make it? Make it with
visitors in mind (so making it a bit technical won't do much harm) or
make it so that Everyone can use it, even the completely new linux
user which only knows a few basic computer things?
The initial proposal sounds like the latter.
Also if making it for the last group (which i expect) than it might
handy to make something of a firefox plugin (or something else) as
well to just click "install" in the WebUI and than the package gets:
Downloaded and Installed. And then i don't mean the normal FF download
window and then double clicking on the rpm file.
That could be handy but it would need to be talked over with the
PackageKit authors rather than me :-)