Re: Getting descriptions for cgit

[Owen Taylor <otaylor redhat com>]

On Fri, 2009-03-20 at 11:27 -0500, Shaun McCance wrote:
> On Fri, 2009-03-20 at 00:18 -0400, Owen Taylor wrote:
> > One missing piece on git.gnome.org right now is to be able to set the
> > descriptions for http://git.gnome.org/cgit/. The current method is
> > "ask someone in the gitadmin group to do it for you", and they 
> > 
> >  echo "Next generation GNOME desktop shell"  > /git/gnome-shell.git/descripotion
> > 
> > Some ideas about how it could work:
> > 
> >  A) We could have another special command to set the description
> > 
> >      ssh git.gnome.org set-description gnome-shell "Next generation GNOME desktop shell"
> > 
> >     This is really trivial to implement, but means no version control, no logging
> >     of who changed what to what, etc.
> > 
> >  B) We could use a DESCRIPTION file checked into the module and pull that
> >     out in a hook.
> > 
> >     This clutters every project with another file containing almost nothing
> > 
> >  C) We could add a line to MAINTAINERS
> > 
> >       Description: Next generation GNOME desktop shell
> > 
> >     Sort of weird to have in maintainers. I also don't know what parses MAINTAINERS
> >     and would have to be adapted.
> 
> Mango and Pulse read MAINTAINERS, as far as I know.  I'm
> pretty sure both of them will just silently ignore a line
> like this.
> 
> For Pulse, I'd love to actually get that information, so
> having it in version control would be great.
> 
> >  D) We could revive the DOAP idea
> > 
> >     I thought it was a quite reasonable idea, but it generated a fair bit of  
> >     hostility that I don't fully understand.
> > 
> >     Hmm, we could make:
> > 
> >      ssh git.gnome.org set-description gnome-shell "Next generation GNOME desktop shell"
> > 
> >     read your maintainers file, combine it with the provided description, generate
> >     a skeleton DOAP file, check it into your module in the MASTER branch... Or 
> >     slightly less crackrock, we could have
> > 
> >      ssh git.gnome.org generate-doap gnome-shell > gnome-shell.rdf
> > 
> >     And you have to edit the skeleton yourself and check it in. If we didn't require
> >     people to write a <description/> then it would only be a few seconds per module,
> >     and that mostly in coming up with a short description for your module. Filling
> >     in your home page takes no time or thought.
> 
> I think people largely opposed the verbosity of RDF.  

Looking through the discussion again:

 - There was one person who didn't like XML
 - There was one person who didn't want to write XML manually
   for his dozen modules
 - There was one person who thought the information was all in
   AUTHORS/README/MAINTAINERS anyways
 - There were a couple people worried about having to update
   versions in doap files by hand

And there were more people who liked the general idea.

> Plus, there were concerns about redundant data, since a lot of
> stuff you'd find in a DOAP file can be found elsewhere in
> the module, if you know how to get it.

The information largely *isn't* elsewhere. If we did put DOAP files in
modules (something that Olav actually wasn't proposing, on the
subsequent read-through, but IMO the right thing), we'd want to avoid
having release information in there. That would be better solved by some
sort of post-processing step that pulled the .doap file from git and
then added the release information from a lookaside.

> I wonder if we could define some sort of non-RDF project
> info file format that people actually wouldn't mind using.
> Something flexible and well-defined enough to provide more
> information that could be picked up by Pulse, but still
> plain-text enough that humans would write and read it.

It's definitely possible. Do we really want to be the custodians of the
"like DOAP but reformatted as a INI file" file format, though? I wonder
how much resistance there would be if we made it really easy to suck
together existing information and create a skeleton you just edit...

- Owen