On Fri, 2008-03-28 at 00:25 +0100, Mark wrote: > 2008/3/27, John (J5) Palmieri <johnp@xxxxxxxxxx>: > > > > On Thu, 2008-03-27 at 21:38 +0100, Mark wrote: > > > 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.. > > > > > > What are you good at? Even having someone write templates and > > javascript are important. 70% of my work is in JavaScript with JSON. > > I can do javascript with jQuery > and i can probably do JSON as well. > templates is also not a problem > > > 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. > > yeah learn something new.. well i want to learn C, C++ and Vala. > python isn't really high on that list but i also want to learn that > one. (damn that's gonna be a lot of programming languages in my head > (php, java, c, c++, vala, html, css, python, javascript)) > > > > > > > > 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 > > javascript because of browser security preventing cross site > > communications. Basically what I do is setup a json call on MyFedora > > and have that call the xmlrpc from the server. > > bottleneck... no python knowledge (yet) > > > > > > > > if so.. where are they? > > > > > > yum install koji > > koji --list-apis > > nice > > > > > That will show you the api's. > > > > Thanx for the info > > > 2008/3/28, John (J5) Palmieri <johnp@xxxxxxxxxx>: > > > > On Thu, 2008-03-27 at 23:00 +0100, Mark wrote: > > > Oke everyone i made a nice little html + javascrip page of a possible > > > solution to make it suitable for the developer AND the completely new > > > linux users. Take a look here [1] and see for yourself. > > > > > > I didn't spend any time at the look (obvious) but it's just to get the > > > idea of what is possible today. the link works 100% fine in FF but IE > > > might show it a little different. > > > > > > So what do you think of it? btw.. done in about 40 minutes. Also the > > > ajax technology is NOT used in this example but if something like this > > > is gonna be made for real than i think using ajax here to load the > > > developer information would be a perfect fit. > > > > > > [1] http://fedora-webui.mageprojects.com/ > > > > > > > > Looks good, a couple of comments: > > > > This is more suited to an application view as you have the install link. > > For package view I would want to see the latest versions built and > > released in each of the important repos (devel, F-8, F-7, RHEL-5, > > RHEL-4, RHEL-3) with the ability to see all the builds. > > Agreed > > > If a specific > > package version is selected it should show if it is released and in what > > version. > > Well.. this is just a example of how it could look.. Agreed on the > idea but can be different in other packages > > > The icon should be grabbed from the package if it has one, > > same with the description (perhaps we could allow wiki like editing here > > for better descriptions, but I feel that is only good if it can somehow > > update the package too). > > Hehe this is just html and javascript ^_^ i didn't add in full xmlrpc > and json calls to get that information but again Agreed! The wiki like > idea is awsome but that it would have to have right permissions to the > koji database in the specfile section. And for that (to keep somekind > of a log) it would probably be best to split the specfile in sections > in the database. so the %description is in a seperate column, the > %files list is in a seperate column etc.. > > > > > If you are doing packages it is geared towards developers anyway so > > there is no need for the Developer Info link. Instead I would have > > direct links above the comments or even as a sidebar for things like > > patches, source tarball download, dependency tracker, etc. For things > > that are useful to be on the main page but hidden such as file lists > > another section that when clicked on expands. > > > > That's a lot of stuff to hide and have links to. Perhaps there should > just be a "More information" that opens the sidebar in which you can > choose what information you would like to see. Than the sidebar > contains _everything_ that is known of the package. That would be > better i think. So partly agreed with modifications. > > > Oh and upstream info is just as important as the package info so the > > upstream stats such as where to get the original sources and homepage > > info. In the future even showing that a new version has been released > > would be great but one step at a time. > > > > I can't imagine that those things can be hard to add _unless_ that > information is not stored in it's own column and thus has to be > grabbed out of the specfile. and the new version release should be > possible now judging from the koji tags i see everywhere.... > > I will try to add in that sidebar stuff tomorrow just to see how that > would work. also making the page on 100% width. Another good thing to do before diving to far into the mockup is to take a screenshot of various package web systems and in the gimp or in a similar way, point out the sections which are important so we can assign labels. I would suggest setting up a wiki page off of the MyFedora wiki page (http://fedoraproject.org/wiki/MyFedora) for package info. Once we have a list of labels you can then do the mockup using the labels as placeholders. We can drill down this way to finally get a list of data you want to grab. I can then fill in the backend from there. BTW here is the style sheet I am using (it is not complete yet): https://fedorahosted.org/myfedora/browser/myfedora/static/css/myfedora-style.css and the genshi template gives you an idea of the structure we use: https://fedorahosted.org/myfedora/browser/myfedora/templates/packages/master.html https://fedorahosted.org/myfedora/browser/myfedora/templates/packages/builds.html The template language may look a bit weird at first but you don't have to worry about loops and such, just how the css elements are used. -- John (J5) Palmieri <johnp@xxxxxxxxxx> -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
