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