Plugins directory
Rich Bowen
Ali B.
I dont have access to upload this but I figured that someone with access would find it easier to just appends the content of the file to the current .htaccess file.
Feel free to review this for lingual and/or technical mistakes :)
--
Ali B / dmondark
http://www.awhitebox.com
... or perhaps a .htaccess file containing AddDescription lines, stating as briefly as possible what these things do, so that I don't have to download and unzip every one of them to find out?Thanks.
Michael Bishop
tags for "stable" releases, and those go to the /dist/ directory. I
realize there's a lot of discussion still to be had about the repo in
general, but I think we need to start being sympathetic to non-dev
type users we are trying to attract. As I understand it, those zips
are snapshots of a latest commit, and can be b0rked. I'm not sure
what all would be entailed to the process, and who would determine
what is "stable", but I'd say at least a revision that works with .4.1
would be nice to have.
Anyone else brave enough to be working with trunk should be capable of
getting the <head> of extras also.
Just my $0.02
~miklb
On Apr 2, 8:31 am, Rich Bowen <rbo...@rcbowen.com> wrote:
> http://habariproject.org/dist/plugins/lists plugins. Very nice.
Michael C. Harris
>
> On that note, I think it's time that plugins in extras start getting
> tags for "stable" releases, and those go to the /dist/ directory. I
> realize there's a lot of discussion still to be had about the repo in
> general, but I think we need to start being sympathetic to non-dev
> type users we are trying to attract. As I understand it, those zips
> are snapshots of a latest commit, and can be b0rked. I'm not sure
> what all would be entailed to the process, and who would determine
> what is "stable", but I'd say at least a revision that works with .4.1
> would be nice to have.
>
> Anyone else brave enough to be working with trunk should be capable of
> getting the <head> of extras also.
I agree we need to split the -extras. How about trunk and tags (with
standardised naming of tags), with the latest tag being put
automatically onto /dist as all -extras commits are now?
I also think Sean's earlier suggestion of owners or maintainers for
everything in -extras is something we should do.
--
Michael C. Harris, School of CS&IT, RMIT University
http://twofishcreative.com/michael/blog
Andrew da Silva
/extras/feedburner/trunk - To install with Habari's HEAD
/extras/feedburner/stable - To install with Habari's latest stable
release
Splitting /extras at the root would be a PITA to maintain.
What I'm wondering is who's going to be the maintainer of each
plugin's stable.
As much as I'm for liberty, there should be strict guidelines (like
Habari's trunk) and appointed people to build the zips.
miklb was talking about having zips built on the fly, don't know SVN
enough to figure that out.
On Apr 7, 8:42 pm, "Michael C. Harris" <michael.twof...@gmail.com>
wrote:
Michael C. Harris
>
> Suggestion:
>
> /extras/feedburner/trunk - To install with Habari's HEAD
> /extras/feedburner/stable - To install with Habari's latest stable
> release
The reason I suggested tags was that at some point we will support
more than one release.
> Splitting /extras at the root would be a PITA to maintain.
I wasn't suggesting that, sorry if I wasn't clear.
> What I'm wondering is who's going to be the maintainer of each
> plugin's stable.
I'm not sure what you mean. I'm happy to be the maintainer of all the
plugins I've committed. If other people put their hand up and say
they're happy to maintain theirs, that's fine. If there are some that
don't have a maintainer, we can discuss what happens to them then.
> As much as I'm for liberty, there should be strict guidelines (like
> Habari's trunk) and appointed people to build the zips.
What sort of guidelines were you thinking of?
> miklb was talking about having zips built on the fly, don't know SVN
> enough to figure that out.
We do that now, afaik. That's what's in /dist.
Andrew da Silva
wrote:
>
> > Suggestion:
>
> > /extras/feedburner/trunk - To install with Habari's HEAD
> > /extras/feedburner/stable - To install with Habari's latest stable
> > release
>
> The reason I suggested tags was that at some point we will support
> more than one release.
>
> > What I'm wondering is who's going to be the maintainer of each
> > plugin's stable.
>
> I'm not sure what you mean. I'm happy to be the maintainer of all the
> plugins I've committed. If other people put their hand up and say
> they're happy to maintain theirs, that's fine. If there are some that
> don't have a maintainer, we can discuss what happens to them then.
maintainer goes away for some time.
Who should take over, and I wasn't talking about the code itself, but
the releases (stable) of the plugin.
Some sort of release manager for each plugin, or all plugins.
>
> > As much as I'm for liberty, there should be strict guidelines (like
> > Habari's trunk) and appointed people to build the zips.
>
> What sort of guidelines were you thinking of?
no .ThumbsDB :P
Do we put the files in a folder, or not, etc..
>
> > miklb was talking about having zips built on the fly, don't know SVN
> > enough to figure that out.
>
> We do that now, afaik. That's what's in /dist.
ringmaster
> On Apr 8, 1:48 am, "Michael C. Harris" <michael.twof...@gmail.com>
> wrote:
>
> > On Mon, Apr 07, 2008 at 10:03:54PM -0700, Andrew da Silva wrote:
>
> > > Suggestion:
>
> > > /extras/feedburner/trunk - To install with Habari's HEAD
> > > /extras/feedburner/stable - To install with Habari's latest stable
> > > release
>
> > The reason I suggested tags was that at some point we will support
> > more than one release.
>
Let's split the extras repo at the root. The reason we'd split the
repo at the root is so that we can allow a group of "contributor"
users access to commit to the repo just like we do, but via the single
trunk branch, while restricting commit access to the release tags to
specific logins. An alternative would be to assign contributor
permissions into each plugin and theme trunk subdirectory, which could
get messy.
Everyone will have access to commit to trunk, but only the *server*
will have commit access to the stable branches. A project maintainer
would have access via the web site to publish a new version of any
plugin in trunk. The interface for this would allow him to enter an
update description and status for the beacon. The server would update
the beacon, create the version tag in svn, and produce the
distribution zip file.
Potential additional features could be to add new repo directories
from the server, and to provide a non-svn interface for interacting
with svn. For example, we could allow theme builders to upload a zip
file of their theme, which would be extracted into a working copy of
their theme from svn, then committed from the server itself. This
might help get around some themers' reluctance to using the repo.
> > > As much as I'm for liberty, there should be strict guidelines (like
> > > Habari's trunk) and appointed people to build the zips.
>
> > What sort of guidelines were you thinking of?
>
> Compression, no DSTORE (or whatever is the Mac OS X hidden file)
> no .ThumbsDB :P
> Do we put the files in a folder, or not, etc..
it's building the zip files itself. Actually, this is already the
case. Under no circumstances should a zip file be released on hp.o
that is not built from svn.
> > > miklb was talking about having zips built on the fly, don't know SVN
> > > enough to figure that out.
>
> > We do that now, afaik. That's what's in /dist.
>
> How do does get created?
There's a post-commit script that executes which builds the files for /
dist.
Owen
Michael C. Harris
> On Apr 8, 1:48 am, "Michael C. Harris" wrote:
> > On Mon, Apr 07, 2008 at 10:03:54PM -0700, Andrew da Silva wrote:
> >
> > > What I'm wondering is who's going to be the maintainer of each
> > > plugin's stable.
> >
> > I'm not sure what you mean. I'm happy to be the maintainer of all the
> > plugins I've committed. If other people put their hand up and say
> > they're happy to maintain theirs, that's fine. If there are some that
> > don't have a maintainer, we can discuss what happens to them then.
>
> Indeed, it's for those who get left behind, or for example, if the
> maintainer goes away for some time.
> Who should take over, and I wasn't talking about the code itself, but
> the releases (stable) of the plugin.
> Some sort of release manager for each plugin, or all plugins.
What I was suggesting is let's set up a system if there are any
plugins that don't have a maintainer we can deal with it then. One
step at a time.
> > > As much as I'm for liberty, there should be strict guidelines (like
> > > Habari's trunk) and appointed people to build the zips.
> >
> > What sort of guidelines were you thinking of?
>
> Compression, no DSTORE (or whatever is the Mac OS X hidden file)
> no .ThumbsDB :P
> Do we put the files in a folder, or not, etc..
All dealt with in be subversion hook script.
> > > miklb was talking about having zips built on the fly, don't know SVN
> > > enough to figure that out.
> >
> > We do that now, afaik. That's what's in /dist.
>
> How do does get created?
I haven't read his email yet, but I think Owen answers the question.
Michael C. Harris
Splitting the whole -extras repo sounds like the way to go. The second
part of your idea sounds like plugin content types, which I've been
mulling over for a while as a way to show off plugins. An additional
feature of the plugin content type might be to allow users to "Add
this plugin to my download bundle" so that users can browse the plugin
posts on hp.o and download a bunch of them at once to be unzipped in
user/plugins.
> Potential additional features could be to add new repo directories
> from the server, and to provide a non-svn interface for interacting
> with svn. For example, we could allow theme builders to upload a zip
> file of their theme, which would be extracted into a working copy of
> their theme from svn, then committed from the server itself. This
> might help get around some themers' reluctance to using the repo.
... and a theme content type for showing off themes, which could have
a theme switcher built in. Theme authors could use it on their own
sites for themes they don't want to submit to -extras and it could be
used on hp.o for the themes in -extras.
Michael C. Harris
unstable (exact format can be argued about) say +1:
+1
Those in favour of naming a maintainer for everything in the -extras
repo (details can be argued about) say +1:
+1
Ali B.
splitting -extras:
+1
naming a maintainer:
+1
Vicki Frei
these subjects make any sense to me.
V
Scott Merrill
Michael Bishop
On Apr 24, 8:53 pm, Vicki Frei <vka...@bytehaven.com> wrote:
> Abstain - I know nothing about code, and none of the post on either of
> these subjects make any sense to me.
>
> V
themes that numerous people have access to, which is great for
development and community building, however, for users who download
these zips (which are currently being built anytime a new commit is
made), they can be grabbing "in-development" code, or not-ready-for-
prime-time. The proposal is for a system in which we can still offer
this community collaboration on development, yet still maintain some
stability in the actual downloadable package. There's probably still
some discussion as to what the download should be compatible with,
etc, however, as this element of the community grows, we need to tame
it now, for the aforementioned reasons (IMO). I also see this as a
extension of fostering potential PMC members.
Just to clarify.
>
> Michael C. Harris wrote:
> > Those in favour of splitting the -extras repo into stable and
> > unstable (exact format can be argued about) say +1:
>
> > +1
>
> > Those in favour of naming a maintainer for everything in the -extras
> > repo (details can be argued about) say +1:
>
> > +1
portion meaning a single "maintainer" per project
~miklb
Vicki Frei
(and that's on my "good" days....)
In that case, probably I'm +1 as well....
V
Michael C. Harris
> > Michael C. Harris wrote:
> > > Those in favour of splitting the -extras repo into stable and
> > > unstable (exact format can be argued about) say +1:
> >
> > > +1
> >
> > > Those in favour of naming a maintainer for everything in the -extras
> > > repo (details can be argued about) say +1:
> >
> > > +1
>
> +1 to both -assuming I follow the discussion about the maintainer
> portion meaning a single "maintainer" per project
Yes, that's the vote I was proposing, that one person be "responsible"
for each project. That doesn't necessarily mean that they'd do all the
coding necessary or anything like that, but they'd be the person to
contact and keep an eye on any issues.
Christopher Davis
Colin
Every cloud has a silver lining... except for the mushroom shaped ones, which have a lining of Iridium & Strontium 90.
Christian Mohn
Christian Mohn
> -----Original Message-----
> From: habar...@googlegroups.com [mailto:habar...@googlegroups.com]
> On Behalf Of Michael C. Harris
> Sent: 25. april 2008 10:55
> To: habar...@googlegroups.com
> Subject: [habari-dev] Re: Plugins directory
>
>
Rich Bowen
Those in favour of splitting the -extras repo into stable and
unstable (exact format can be argued about) say +1:
+1
Those in favour of naming a maintainer for everything in the -extras
repo (details can be argued about) say +1:
+1
Michael Bishop
On Apr 26, 8:29 pm, Rich Bowen <rbo...@rcbowen.com> wrote:
> On Apr 24, 2008, at 20:11, Michael C. Harris wrote:
>
>
>
> > Those in favour of splitting the -extras repo into stable and
> > unstable (exact format can be argued about) say +1:
>
> > +1
>
> +0 , no opinion
>
>
>
> > Those in favour of naming a maintainer for everything in the -extras
> > repo (details can be argued about) say +1:
>
> > +1
>
> -1
>
> Explicitly naming a maintainer for a piece of code has a number of
> negative social impacts, all of which are variations on the same thing
> - this code belongs to Bob, and so I'm reluctant to touch it. Either
> the code belongs to the community, or it doesn't. If it doesn't, it
> doesn't belong in our repo.
"maintainer", and not owner, or author, or some other term that
implied "ownership", I felt more comfortable that it simply indicated
someone taking responsibility for making sure stable releases were
maintained. What if we called them something else? Guardian ;-)
If we weren't to go this route (not having a maintainer), what would
you suggest as a solution for making sure that we were providing users
with a stable, functional plugin that was compatible with the latest
stable release? Or does your +0 vote indicate that you don't feel
that is important at this juncture of the project?
While I'm thrilled at the influx of community development on plugins
and themes, and community attribution for that matter, I have joined
in bringing this up simply because I am afraid of the effect it might
have on a new user. Currently, they can download one of these plugins
at a particular moment that it's buggy (like the other morning when I
made several poor commits), try out the plugin/theme, be turned off,
and move on. Even though we are still "alpha"/ "developer release"
officially,, I think we are really moving towards portraying the
project as as semi-stable for people to check out, which means many
people downloading zipped files, and not doing SVN, IRC, etc. I don't
want to scare them away completely.
I'd also hate to see plugins "die on the vine" because there is no one
tending to it. These people do not have to be "coders", simply
community members who want to volunteer in some fashion.
Finally, there's already a bit of confusion/fear about who's plugin is
who's, regardless of the attribution, and stepping one's toes.
Perhaps this is a good time for someone (is that the sound of me
volunteering?) blogging about what the extras repo is, how it's
intended, and where we see it going.
~miklb
Andrew da Silva
This way we know who to ask for how the plugin behaves/works, without
having to ask him for permission, he's just a reference.
Michael C. Harris
>
> Original Creator.
>
> This way we know who to ask for how the plugin behaves/works, without
> having to ask him for permission, he's just a reference.
What if the original creator joins a monastery and takes a vow of no
internet?
Sean T Evans
Hash: SHA1
Michael C. Harris wrote:
> On Sat, Apr 26, 2008 at 07:47:23PM -0700, Andrew da Silva wrote:
>> Original Creator.
>>
>> This way we know who to ask for how the plugin behaves/works, without
>> having to ask him for permission, he's just a reference.
>
> What if the original creator joins a monastery and takes a vow of no
> internet?
>
If we maintain our rule that items in -extras belong to the community, I
don't think we need to list the original creator. As far as how it
works, we should require documentation to move from the "testing" to
"stable" branches (to steal some nomenclature from Debian).
Here is what I see as a general outline for the flow of plugins/themes
on extras.
1) New developer says "Hey I've got a plugin I'd like to contribute to
extras."
2) An extras "moderator" looks at the code to determine that it is A)
functional and B) not harmful.
3) the "moderator" then makes sure that the submitter is clear on what
the rules for -extras are (credited to the community, no ownership...),
and then sets up access to the "testing" branch for the submitter.
4) The submitter (and anyone else so inclined) can then work in the
branch. When a stable version of the Plugin/Theme is ready for release a
RC zip is made and an -extras moderator reviews it for
stability/functionality/security. Assuming it passes, an entry is
created in the "stable" branch.
Obviously, this will require some fine tuning to work properly, and
there are likely errors I'm not seeing, but I think having "moderators"
may help prevent the "ownership" issues, and like other elements of the
community, they can self-select both on the level of being moderators
(the moderators don't even have to have administrative rights to
- -extras, they can simply pass the information on to someone who does.)
as well as for the themes/plugins that they feel comfortable moderating.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIFALLmQpMBUWJpdsRArMwAJ9CZrJWF0OGTX9MKzOs8ecEX7C5zgCdGcF5
vC7aS6xt17aCEtux7Jx6dgw=
=xoJB
-----END PGP SIGNATURE-----
Michael C. Harris
> On Apr 24, 2008, at 20:11, Michael C. Harris wrote:
>
> Those in favour of naming a maintainer for everything in the -extras
> repo (details can be argued about) say +1:
>
>
> Explicitly naming a maintainer for a piece of code has a number of
> negative social impacts, all of which are variations on the same thing
> - this code belongs to Bob, and so I'm reluctant to touch it. Either
> the code belongs to the community, or it doesn't. If it doesn't, it
> doesn't belong in our repo.
You're right, "maintainer" has connotations that I'm not comfortable
with either. How about "shepherd"?
Some of the problems I see that we're trying to address:
- when someone raises an issue with an -extras plugin, someone should
say "Great, thanks for raising that, we'll look into it." At the
moment, there's often silence. See anything to do with pingback or
wp-importer.
- a plugin that needs work remains stagnant. The wp-importer is a
classic one here, because it is nobody's itch, but it is important.
- releasing plugins from the (soon to be) testing branch to the stable
branch.
- ensuring that the plugin is tested during release feature freezes.
We could be very clear about the fact that this is _not_ someone who
is responsible for "protecting" the code, and the code in no way
belongs to them.
Rich Bowen
Original Creator.This way we know who to ask for how the plugin behaves/works, withouthaving to ask him for permission, he's just a reference.
What if the original creator joins a monastery and takes a vow of no
internet?
Rich Bowen
Explicitly naming a maintainer for a piece of code has a number ofnegative social impacts, all of which are variations on the same thing- this code belongs to Bob, and so I'm reluctant to touch it. Eitherthe code belongs to the community, or it doesn't. If it doesn't, itdoesn't belong in our repo.
I originally felt the same way, but after I thought about the term
"maintainer", and not owner, or author, or some other term that
implied "ownership", I felt more comfortable that it simply indicated
someone taking responsibility for making sure stable releases were
maintained. What if we called them something else? Guardian ;-)
If we weren't to go this route (not having a maintainer), what would
you suggest as a solution for making sure that we were providing users
with a stable, functional plugin that was compatible with the latest
stable release? Or does your +0 vote indicate that you don't feel
that is important at this juncture of the project?
While I'm thrilled at the influx of community development on plugins
and themes, and community attribution for that matter, I have joined
in bringing this up simply because I am afraid of the effect it might
have on a new user. Currently, they can download one of these plugins
at a particular moment that it's buggy (like the other morning when I
made several poor commits), try out the plugin/theme, be turned off,
and move on. Even though we are still "alpha"/ "developer release"
officially,, I think we are really moving towards portraying the
project as as semi-stable for people to check out, which means many
people downloading zipped files, and not doing SVN, IRC, etc. I don't
want to scare them away completely.
I'd also hate to see plugins "die on the vine" because there is no one
tending to it. These people do not have to be "coders", simply
community members who want to volunteer in some fashion.
Finally, there's already a bit of confusion/fear about who's plugin is
who's, regardless of the attribution, and stepping one's toes.
Perhaps this is a good time for someone (is that the sound of me
volunteering?) blogging about what the extras repo is, how it's
intended, and where we see it going.
Rich Bowen
Explicitly naming a maintainer for a piece of code has a number ofnegative social impacts, all of which are variations on the same thing- this code belongs to Bob, and so I'm reluctant to touch it. Eitherthe code belongs to the community, or it doesn't. If it doesn't, itdoesn't belong in our repo.
You're right, "maintainer" has connotations that I'm not comfortable
with either. How about "shepherd"?
Some of the problems I see that we're trying to address:
- when someone raises an issue with an -extras plugin, someone should
say "Great, thanks for raising that, we'll look into it." At the
moment, there's often silence. See anything to do with pingback or
wp-importer.
- a plugin that needs work remains stagnant. The wp-importer is a
classic one here, because it is nobody's itch, but it is important.
- releasing plugins from the (soon to be) testing branch to the stable
branch.
- ensuring that the plugin is tested during release feature freezes.
We could be very clear about the fact that this is _not_ someone who
is responsible for "protecting" the code, and the code in no way
belongs to them.
Andrew da Silva
If someone wants to do a stable release, he should ask Habari PMC for
permission, and PMC will attribute SVN permission...
This way it can be anyone at anytime of the occasion is right.
On Apr 26, 11:50 pm, "Michael C. Harris" <michael.twof...@gmail.com>
wrote:
Ali B.
Does that make sense, everyone?
Michael C. Harris
> On Apr 27, 2008, at 02:37, Michael C. Harris wrote:
> > >
> > > Explicitly naming a maintainer for a piece of code has a
> > > number of negative social impacts, all of which are
> > > variations on the same thing - this code belongs to Bob, and
> > > so I'm reluctant to touch it. Either the code belongs to the
> > > community, or it doesn't. If it doesn't, it doesn't belong in
> > > our repo.
> >
> > You're right, "maintainer" has connotations that I'm not comfortable
> > with either. How about "shepherd"?
>
> +1, if it's understood that this can be, and probably should be, a
> fluid position - that is, someone needs to actively maintain the list
> of who the shepherds are, and folks need to be willing to let go when
> it's clear that someone else has taken the reins.
Good point.
> > Some of the problems I see that we're trying to address: -
> > when someone raises an issue with an -extras plugin, someone
> > should say "Great, thanks for raising that, we'll look into
> > it." At the moment, there's often silence. See anything to do
> > with pingback or wp-importer.
>
> At which point, that person has the opening to step forward and grasp
> the reins and go with it. It's Open Source - you can't compel someone
> to work on this, even if their name is on a list somewhere.
The list is completely voluntary. If they don't want to be the person
who it is understood will shepherd the plugin, they can remove their
name.
> > - a plugin that needs work remains stagnant. The wp-importer is a
> > classic one here, because it is nobody's itch, but it is important.
>
> Help me understand how this would work. So, my name is listed on the
> wp-importer, but it's not my itch, because I'm all done migrating off
> of WP. How does having my name on the list make me more likely to work
> on it?
Like I said, it's voluntary. You don't have to have your name on the
list. Anyone who wants to put their name down as the shepherd of a
plugin is saying they will keep the plugin in their mind. They won't
necessarily do the work, they may not even be a coder, but they just
keep it in mind. For example, caching gets introduced in core, the
shepherd might think about whether there are any opportunities for
caching in their flock and raise it on -dev, #habari, or open a
ticket. It doesn't stop anyone submitting a patch to enable caching or
opening a ticket.
This isn't the only issue though, the tagging and testing are
important too.
[snip other points]
> > We could be very clear about the fact that this is _not_ someone who
> > is responsible for "protecting" the code, and the code in no way
> > belongs to them.
>
> Yes, that is perhaps my biggest concern - that 1) folks aren't
> intimidated away from working on it, and 2) people don't get offended
> when someone else works on "their" code.
We just need to be clear on that. It isn't their code. I'm not saying
tickets must be submitted to the shepherd, or that tickets submitted
will be automatically owned by the shepherd.
Christian Mohn
involved. ;-)
> -----Original Message-----
> From: habar...@googlegroups.com [mailto:habar...@googlegroups.com]
> On Behalf Of Michael C. Harris
> Sent: 28. april 2008 08:43
> To: habar...@googlegroups.com
> Subject: [habari-dev] Re: Plugins directory
>
>
Chris Meller
where everything should move to. With two plugins in -extras, I've
already wanted to have a branch to work in while people are grabbing
working code out of trunk.
If things were broken out per -extra, you could also create a 'stable'
tag that constantly represents the code that should be zipped and
dumped.
I also fail to see how breaking things out into {trunk,branches,tags}
is any more or less difficult management-wise than the current system.
Correct me if I'm wrong, but aren't commiters to -extras able to
commit to anything? How is a repo-wide permissions system any
different with or without the extra level per -extra?
Eventually we're going to want -extras to interact with any type of
plugin directory that is established, so that we can tie the two
together based on the "owner" of the code. At that point I don't see
why we couldn't establish a system that generates svn_authz
permissions based on their info from the directory, making sure owners
can only commit to their specific mini-repo(s). Ta-da, no "management"
required.
If you want the ability to have several "maintainers", that's fine.
Create a new authz group for each -extra and add on as many users as
you like. I don't see why this couldn't be done via the plugin
directory by the designated owner (which is the more difficult matter
to decide).
At this point in the life of -extras, there is no reason I see *not*
to create the {trunk,branches,tags} structure under each -extra. If
developers want to use it, fine. If not, they're free to continue only
using their own little "trunk", just as before. Since permissions are
repo-wide anyway, there's no management issue that didn't exist
before.
If we should decide to step up to the plate and create a pseudo-repo
structure for each extra in the future, we'd really be shooting
ourselves in the foot. Instead of having 3 dozen authors and users who
have to switch their SVN targets, now we have 12 dozen. With no real
downside to the move, I don't see why we wouldn't want to save
ourselves the trouble and jump on it now.