Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Alias (5735)

Alias
  (email not shown publicly)
http://ali.as/

Journal of Alias (5735)

Tuesday July 04, 2006
09:35 PM

Best Practices for Collaborative Repositories (draft)

[ #30175 ]

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?

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • A simple solution would be a small CGI script using Authen::Bitcard [cpan.org] 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
    --

    -- ask bjoern hansen [askbjoernhansen.com], !try; do();