Application for GSoC Project - Package WebUI

Thu Mar 27 23:50:44 UTC 2008

On Fri, 2008-03-28 at 00:25 +0100, Mark wrote:
> 2008/3/27, John (J5) Palmieri <johnp at redhat.com>:
> >
> >  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
> >  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 at redhat.com>:
> >
> >  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 at redhat.com>