2008/3/27, John (J5) Palmieri <johnp@xxxxxxxxxx>: > 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@xxxxxxxxxx> 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? -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
