Application for GSoC Project - Package WebUI

[Mark]

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.

> John (J5) Palmieri <johnp at redhat.com>
>

Mark