On Mon, 10 Mar 2008 14:57:39 +0000
"Thaddeus H. Black" <[EMAIL PROTECTED]> wrote:

> This message is copied to A. Costa, who has a
> long-outstanding bug filed against the package and might
> be interested in the package's future (or, conceivably,
> might wish to take over its maintenance himself)

Flattering, but I'm not a Debian maintainer -- for me the whole brick &
mortar handshake "web of trust" thing won't work, I'm not a "joiner",
don't know anybody "in person", and live in a small town.  If it were
up to me I'd revise Debian to have a "web of doubt", but that's another
matter entirely...

On maintaining 'debram':  you've done a good job, but dropping it is
the wrong approach, since it's your baby & credit.  In particular
'debram' isn't a finished work that only needs to be "maintained",
it's a work in progress that requires authorial oversight, sculpting,
and steering -- Noah Webster, Roget, Bartlett, Brewer, et al, weren't
exactly creative artists, but their projects probably would have
fizzled without their respective tastes and good judgements.

Perhaps what's needed are ways of making the maintenance less work, or
virtually no work.  Maybe have some email server or 'wiki'-like
interface that users contributed to, scripts ran sanity checks on, then
the prospective data would be vetted sequentially by a series of
volunteers to guarantee the data was sound.  Disregarding for the moment
whatever time it would take to implement such measures...

Operations such an interface ("invitation only" at first) would do:

        1) add new things, (items, cross refs).
        2) move things around.
        3) delete (or "archive") things.
        4) periodically monitor Debian packages and make a 'todo' list.

Sequential vetting model:

        1) Pool of volunteer reviewers.  Maybe 9 or 10.  An
           upper limit to this number might prevent many 
           diverging opinions.

        2) Changes are checked by three random reviewers, 'Y/N', sequentially.  
           (No reviewer vets their own stuff, except the maintainer.)

        3) All three have backups, if they don't vote after 'n' days,
           their "second" votes.  Possibly "thirds" might be needed.

        4) It passes that, it's in.  Scripts update 'debram' & post it.

        5) Maintainer has retroactive veto, if desired.  

I'm modeling this after a dictionary/encyclopedia staff, with the
redundancy thrown in because nobody can do it full time. Later, if it
worked, more functions and fields could be added, e.g. stats, ratings,
etc.

Rule '2)' above might be too arbitrary.  Maybe multiple choice
questions like this:

        package 'foo' most belongs in:

                a) file utils
                b) net utils
                c) games
                d) <fill in the blank>

Where one of the above is the proposed answer, and the other
two are picked at random.  I'm less sure if unanimity is as necessary
for such a method -- random users might even be good at succesive
iteratons of the above.

All this assumes the main time sink is the 'debram' catalog itself,
if Debian is growing too large for one man to survey.  If the time
problems are just for ordinary of maintenance, then AFAIK you could
deputize users as "co-maintainers", to do little jobs.

HTH...



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to