perceive there are several distinct user classes that are involved, each with
their own needs and capabilities. I want to make sure that we don't go with
some system because it makes one group float on air, and cuts another group off
at the knees.
So here's my take on the different constituencies that can be involved in any
given collaborative software development (and I fit into each, depending on the
0) Package users - this class doesn't compile from source code for the packages
they use (even if they technically could). They may or may not be competent in
C (or even Perl). Consequently, whatever VCS system we choose has no impact on
them in the slightest. I only list them here because we want to make sure that
whatever we choose as the Perl VCS will not be a high bar to moving these people
into #1 below.
1) Casual Developer - this class knows how to compile packages for their use
from source code (though they might normally rely on packages). They can
develop in C and/or Perl with varying levels of competence. When they come
across some limitation or bug, they know enough to be able to scratch their
itch. They may not ever submit more than a single patch. What we choose as a
VCS may have some impact on moving these folks into class #2.
2) Committed Developer - this class has "drunk the koolaid" and is actively
involved in the project (regular posters to p5p probably fall into this
category). This class is much more likely to track development of the codebase
on a more or less regular basis. They may or may not produce patches regularly,
but they should be able to do so on a moments notice. They may need the ability
to research the code history in some detail (say to identify which patch caused
a bug). Some members of this group may never proceed to #3, where others will
dip in and out.
3) Core Developer - this class is actively targeting new features in the core.
They have a need for a branch for active development of [possibly destabalizing]
changes to the core. Any branch they use is more than likely to be long lasting
so merging from mainline is critical. Whether any branch is public or private
is very dependent on the actual feature; sometimes a public branch is best (many
eyes makes for light work), and others can work better in private (the
'springing from the forehead' model). People who are maintaining dual-life
modules are probably in this class (but not always).
4) Full Committers - this class is actively involved in driving the patches
produced by #1-#3 into the core. This class may or may not *also* be involved
in the kinds of activities of #2-3, but in their role as Committers, they have
5) Pumpkings - like a super committer, they are the ultimate arbiters for new
features and decide when a release is possible/required. They have even more
specialized needs than #4. For example, perl-maint must be able to backport
bleadperl patches at any level of granularity.
Personally, I think I'm about at 2.5 or so; the version object code took a lot
longer than I had anticipated/hoped, and I had to keep closely up to date with
changes in bleadperl for an extended period of time (particularly during the
waves of const'ing).
Do these divisions seem meaningful? Should I add this to the wiki so we can
start fleshing out what that means for our future VCS choices?
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Blvd
Lanham, MD 20706