I realize you may be near the end of your patience, but think about this: in the long run, either you play the game the way other Slimers do, or you end up maintaining a fork. If that's what you want to do, fair enough.
imho, slime is naturally a project of many branches because everyone has their own desires that may or may not be meant for public consumption.
darcs is a great tool for that (when used properly*), because its internal state is a semi-ordered list of diffs, where the ordering is the dependency between the diffs on line-level granularity. as long as you record independet patches you can freely transfer them between the branches as simply as a 'darcs pull'/ or 'darcs push' and therefore each copy of a repo is a branch on its own right.
so with darcs you can exchange patches like stamp collectors exchange stamps: just announce a cool patch on the list with a repo link, then people can pull it from you and those with the commit bit can push it into the official branches. this is this simple as long as the patches are recorded in repos that are sufficiently close to each other on the darcs patch level.
(*) always record the smalles possible semantical unit of changes as a patch. do not record deeply nested conflicting patches in different, real** branches because they are a headache when all of them are pulled into a single repo (the simplest problem is a necessity of hand resolution of conflicts, while the biggest is a current darcs deficiency about an exponential algorithm never finishing. this renders the patches incompatible until it's addressed by the darcs devs. but you need two fairly different branches with active development in both of them to be able to record such patches).
(**) you can have simple branches like the dev/stable that are not really branches, only there's a delay in the patches arriving to stable. and you can have "real" branches when you record changes in more then one repo simultaneously which makes it possible to record actually conflicting patches.
i can't fix people's isp connections, i can't read docs for them
This is totally beside the point. No-one has asked for any of these things. Let's _please_ keep this on topic and to the point.
i was just reacting to actual cons brought up against darcs here.
Frankly, if it settles down the dust, I'd be willing to move Slime to Darcs + monthly timeboxed releases. I'm not willing to move Slime to Darcs and retain current "release practise", though -- Darcs is still esoteric enough to make that a bad proposition in my mind.
i think it would be enough to have two (or more) official branches like slime.stable, slime.dev, etc where people are liberal in pushing to the dev branch and only pull patches to the stable branch from the dev branch with a delay (and consensus on questionable changes).
there's also darcs undo to easily record a reverse patch when there's a veto. (unpulling from a public official repo is a no-no because some users may have pulled the patch already)
then less active users can choose the stable branch and the more active users can use the dev branch. and even they can remove a problematic patch from their local repo as easily as a 'darcs unpull' while the debate is going on on the list.
now this all is much less convenient if the stable branch is a cvs repo and i'm the only one using the darcs repo (currently at http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cl-wdim-slime;a=summa... ), but it's still simpler for me as long as the two repos are sufficiently close to each other (and therefore there are no, or only a few conflicts while converting the cvs chages into the darcs repo).
i hope this makes it clear why i prefer to use darcs and that it's not an intention of mine to maintain a fork. btw, in the current situation i don't consider the darcs repo as a fork, only a convenient way to store our (the dev team i'm working in, Levente made the new in-place fuzzy gui) changes and distribute them between us (and anyone interested).