Application for GSoC Project - Package WebUI
John (J5) Palmieri
johnp at redhat.com
Thu Mar 27 22:51:01 UTC 2008
On Thu, 2008-03-27 at 21:38 +0100, Mark wrote:
> 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..
What are you good at? Even having someone write templates and
The backend is there to pull data. Also, this is Summer of Code, a good
time to learn something new if you already know other server side
languages. TurboGears and python is pretty much our infrastructure. It
makes doing things like utilizing FAS2 for single sign-on quite easy.
> Are there any docs on that koji database communication with xmlrpc?
That is all done with the koji python module. It can't be done via pure
communications. Basically what I do is setup a json call on MyFedora
and have that call the xmlrpc from the server.
> if so.. where are they?
yum install koji
That will show you the api's.
John (J5) Palmieri <johnp at redhat.com>
More information about the devel