On Thu, 8 Feb 2007, Magnus Holmgren wrote:
> On Thursday 08 February 2007 12:10, David Woodhouse wrote:
> > Out of interest rather than an immediate desire... I see that there are
> > other people committing to CVS occasionally. I think I also have commit
> > access to CVS, so theoretically I could also do so.
>
> I can confirm that.
>
> > Under what
> > circumstances (if any) would that be acceptable? Do we get you to
> > approve each commit in advance; are there any existing guidelines? I'm
> > not even aware of any informal convention about it, if such exists.
>
> I don't know, but I guess that if you break something, you fix it, at
> least. :-)
On the whole, people seem to send code patches to me for my review, even
when they have commit access. There have been exceptions, of course.
Apart from eximstats, which Steve maintains, and the content-scanning
code, which Tom maintains, I think the files committed by others are
mostly infrastructure files of various kinds.
It might be helpful to outline what I do when making a change to Exim:
. If it is a bug fix, I try to create a test in the test suite that
demonstrates the bug. This isn't always possible, of course. After
editing the code, I run the test to make sure the change does what it
is supposed to. I then run the whole test suite to check for unwanted
side effects.
. If it is an enhancement, I run the test suite after doing it, to check
for unwanted side effects. Then I either add a new test or modify one
of the existing tests to check the new feature.
. I update ChangeLog, and, if relevant, NewStuff, OptionLists, and
ACKNOWLEDGMENTS. I usually scribble on my printed copy of the manual
as well, as another reminder of what needs updating for the next
edition.
. Then I commit.
--
Philip Hazel University of Cambridge Computing Service
Get the Exim 4 book: http://www.uit.co.uk/exim-book
