Best Practices for Collaborative Repositories (draft)

Alias on 2006-07-05T02:35:45

I've now had my collaborative repository running for 10 weeks, so I thought for the benefit of other CPAN authors moving in the same direction I'd outline some observations over this initial period.

----------------------------------

1. It takes a while to get up to speed

Don't expect a flood of commits, or any, for a while.

People's priorities vary greatly, and while they might have previously had timeslices when they first filed a bug, they might not have now. They may not WANT to use the repository at all.

But that's fine, because the NEXT time they have a nit, they will do it in the repository that time. And once they've made one change, they are much more likely to do it again later.

2. Be very clear on what committers must do

However you provide access, be clear about what committers are expected to do. Be clearer than you think they need, just in case.

3. For small stable modules, commiters should prep the next release.

For my repository I only give accounts to CPAN authors, so I can assume they know how dists work.

What seems to work best is that the commiter add their change, increment the version and update Changes themself, then just ping me to review and release.

This seems to minimise the amount of interaction required, and reduces the chance for mistakes.

4. For new unstable dists, pressure committers to actually commit.

For modules that AREN'T on CPAN yet, or are new and unstable, there seems to be a tendency for committers to be tentative about committing until they are completely happy with it.

This makes is much harder for you to follow up or help them out, and seems to slow work down as a result. I'm still dealing with this reluctance to commit early/broken code myself, so no ideas how to fix it yet.

I'm wondering how much svk makes this problem worse. The user commits incrementally as normal, but doesn't push it up to you until its "done"...

5. Big modules are all different

As for big projects, I suspect there won't be hard and fast rules, because they often have their own management structures you can't apply simple rules to.

----------------------------------

Your thoughts? Your experiences?


SVN authentication

ask on 2006-08-03T13:12:10


A simple solution would be a small CGI script using Authen::Bitcard to authenticate people and let them set a local SVN password. (That's basically what we do for svn.perl.org).

(Most of the perl.org services uses Bitcard, so many CPAN contributors will have an account there (too)).

  - ask