Re: [Gnu-arch-users] Proposal: tla tree-description

[Tom Lord]

    > From: Rob Kaper <address@hidden>

    > I'd like to know if anyone else is interested in an extension to arch to 
set
    > a description for a project:

    > tla tree-description [options] [description]

I am.   (However....)

    > to list or set a short description for a project tree. I've started to 
work
    > on a graphical client to browse archives and noticed that a concise tree
    > description would definitely be useful to have somewhere.

    > Take the following abrowse output as example:

    > address@hidden
    >   atlantik
    >     atlantik--mainline
    >       atlantik--mainline--0.7
    >         base-0 .. patch-8
    > <snip>

    > What's that all about then? Who knows! 

Exactly right (the criticism, I mean).


    > Adding a description would encourage people to browse archives
    > because it decreases the chance they download something they
    > don't really want and likewise increases their ability to find
    > what they do want.

    > For example, Atlantik would be described as "KDE client for
    > Monopoly-like board games with monopd".

    > Although this won't necessarily benefit people who find a project and as
    > such know it before they know archive locations, it will assist people who
    > download software from particular authors and wonder what other goodies a
    > certain author/vendor might have written.

    > Comments?

Completely nice feature goal and rationale.

However....   details matter.

What do you want to bind descriptions to?  Archives? Categories?
Branches? Versions?  (Revisions already have a Summary: line in the
log.)  

It's tempting, feature-goal-wise, to say "Yes, to any of those
things" so that, for example, [ar]browse can report the archive
description, the description of a particular version, etc.

And then the next question is implementation.   Where does this data
get stored?

Long ago, arch actually _had_ this feature in a nascent form.
Archives could contain =README files (rfc822-ish format) for the
archive, each category, each branch, etc.....

This is exactly what you want.

The feature was removed because, _when_naively_implemented_, it made
push-mirror absurdly slow.   By "naively implemented" I mean, for
example, that if I wanted to push just a handful of new revisions to a
mirror, nevertheless, _all_ of the =README files were copied to the
mirror (because there was no cheaper way to recognize  if they might
have changed).

That's a solvable problem but solving it is a prereq for adding this
feature back.   There's actually an opportunity there because
push-mirror could use some speeding up anyway and the same solution
that enables the feature you have in mind might be able to speed up
push-mirror generally.

And there's a relatively new twist on the problem: interaction with
signatures.  =README files (or however the description data winds up
being stored) will now need to be signable.

There is an alternative approach to speeding up push-mirror and using
=README files and that is to store the description (and other
metadata) in "shadow projects".

For example, if I my archive has:

        tla--devo--1.2

then I'd be willing to snarf some namespace so that the description
for that is stored in the most recent log message of something like:

        META-tla--devo--1.2

It would take a little bit of work to come up with the right mapping
between names, but overall this would be a low-impact change that
results in the feature you want.


-t