[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Proposal: tla tree-description
From: |
Tom Lord |
Subject: |
Re: [Gnu-arch-users] Proposal: tla tree-description |
Date: |
Tue, 2 Mar 2004 09:42:40 -0800 (PST) |
> 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