Application for GSoC Project - Package WebUI
Mark
markg85 at gmail.com
Thu Mar 27 20:38:31 UTC 2008
2008/3/27, John (J5) Palmieri <johnp at redhat.com>:
> So, MyFedora, while being developer targeted is taking a user designed
> approach. What this means is that instead of displaying all the
> information in the world about a subject (say packages) it displays the
> most common actions and information a developer would need in their day
> to day work. For instance, I am working on the build page and what it
> shows is what builds were done for a package, if there is an error it
> will display a link for the log that is most likely to have the error in
> it. If there are downloads available it will show only the package and
> sub packages, excluding debuginfo and devel for the arch the user is
> running on. There is a more link to see all of the downloads so I do
> add some drill down facilities but it is not a priority. The part I am
> working on now is if the package is in testing or candidate repos and
> you have the rights to request a push it will have an action to push to
> a release via bodhi. And that is just the builds page. In every case I
> pull from our existing tools via json or xmlrpc instead of recreating
> databases.
>
> Now that I have outlined the development mentality for MyFedora I have a
> couple of ideas where this GSoC Project should fit in.
>
> First, there are two elements we want to consider, a package database
> and an application database. Users care about applications (a
> collection of packages which make up a program which is usually launched
> from a menu), developers care about package (a collection of
> interrelated files and rules for putting them on a disk as well as
> specifying dependencies). One tool could most likely have a UI and DB
> to fit both with minor tweaks.
>
> If you want to just make a data mining tool it will most likely be
> better off as a separate TurboGears project in which MyFedora could
> access its data based off of specific packages.
>
> If you wanted it to be part of MyFedora you will have to think in terms
> of the users, what do they want to see, how do they want to see it, what
> actions would they need and how does it integrate with other Fedora
> tools.
>
> Personally if it was part of MyFedora I would want it to be much more
> than just a view into a package. I would want people to be able to
> write comments, have annotations for the next build, be able to trace
> unneeded dependencies, be able to see and download patches to send to
> upstream, and it should be able to do this without looking like the barf
> of information the Debian package db is (however useful that barf of
> information is ;) In other words it should be a tool towards making
> fedora packages and the upstream sources they pulled from better.
>
> If you are up for that challenge (and I am not saying you have to get it
> all done but move in that direction) then it will be a perfect fit for
> MyFedora. I would be happy to mentor.
>
>
> --
> John (J5) Palmieri <johnp at redhat.com>
I'm interested and willing but python stops me..
Are there any docs on that koji database communication with xmlrpc?
if so.. where are they?
More information about the fedora-devel-list
mailing list