I'm experimenting with opening up CVS access somewhat.
This will be a new experience for me in a number of ways, among them
that I've never worked on a project with shared CVS commit privileges.
There will probably be some stumbles. I don't know what conflicts, bug
problems, morale problems, political maneuvering, or other issues will
arise. Hopefully this will be one of those not-vanishingly-rare things
which works more smoothly than I deserve. We'll see.
Right now the new policy, such as it is, is basically laziness on my
part. I don't want to be a bottleneck, but I have only so much energy
for promptly reviewing patches. Ergo, it's appealing to give CVS
commit privileges to people who submit enough patches to tire me out,
and further whose ideas about software match mine enough and whose
code is careful enough that I end up more or less rubber stamping
their patches. As an immediate exercise of this laziness, any of you
who obsessively cruise the SBCL project page on SourceForge will've
noticed that crhodes is now listed as a developer.
There are a number of software engineering issues involved in
synchronizing commits. My understanding is that in practice CVS
collisions are much less of a problem than one might fear, and
in general heavy policy and procedures are unnecessary. For now,
* Neither Christophe nor I has immediate plans that should
step too heavily on each others' toes. Later, as things change
and multiple developers and big change plans intersect,
informal e-mail notices and negotiation might suffice, or
some other notification mechanism might be called for.
* I propose that we keep using the current manually-updated
linear version numbering scheme (e.g. sbcl-0.7.1.34).
I think that aside from race conditions involving different
committers checking in their work at exactly the same time,
that should be fairly easy to do with "cvs update", followed
by incrementing one's local version.lisp-expr, followed by
"cvs commit". I'm a little foggy on how cvs collision stuff
works out in practice, though, so there might be more issues
There are also peopleware issues. E.g.
* I'm concerned that there might be much more friction when
I approve committers instead of approving patches. "I don't
approve you as a committer" seems much more likely to give
offense than "I don't approve of this patch". And it's much
easier to give a point by point objective justification
for rejecting a patch than for not giving CVS access. I'll start
with just good intentions and my "common sense", such as it
is, for approving CVS access (and the reminder that CVS access
is a token of my laziness, not a software engineering merit
badge:-). Hopefully in practice people will cut me enough slack
that this is all the policy that'll be needed. But I'm
definitely not savvy enough to predict how this will work out.
* Rather than constantly taking the pulse of the project and
deciding when it's ready to release, or trying to get a
consensus of people doing that, I'm inclined to make
a schedule of releases and corresponding quasi-freezes
before them, and let committers synchronize their commits
with that pulse. As a tentative start, I propose releases late
in "each" month, with a quasi-freeze testing period starting
on the 20th of the month and running up to the release.
During the quasi-freeze we should only commit changes
which are either fairly safe bug fixes (where the appropriate
simplicity limit is related by the severity of the
bug being fixed) or which are trivially safe (e.g. comment
fixes). The idea is that making the system buggier is always a
sin, but it's an especially grave sin during the quasi-freeze
period. This way, among other things, the quasi-freeze period becomes
a particularly good time for people who care about the stability
of the next release to test on their preferred configuration.
"Each" month may end up being not quite each month, at least as
long as I'm personally responsible for doing the releases, since
there are occasionally months when I might warn in advance that
I'll be distracted, and it may also happen either that I'm
unexpectedly unable to do it some month, or else that we end
up with enough bugs or other issues that we delay a release.
* Christophe pointed out that there have been quasi-pedagogical
advantages to having patches posted on sbcl-devel. My guess is
that there will still be enough patches posted that we'll get
most of this benefit. But as a fallback, I've also created a
<http://ww.telent.net/sbcl-internals/CVS> page for, among other
things, recipes to tell people how they can extract change
information from the CVS repository, so they can synthesize
their own "patch" representing any change which interests them.
(Actually, that entry on the page is still a placeholder. Bug
me that bugs you, otherwise it might remain a placeholder for
Comments and suggestions are welcome.
William Harold Newman <william.newman@...>
"Among animals, it's eat or be eaten. Among people, it's define or be
defined." -- Nancy Lebovitz
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C