After the recent discussions, I felt it may be useful to codify what I
see as the current CVS commit guidelines for project developers. The
current text is up on the wiki:
http://panoptic.com/wiki/aolserver/CVSCommitGuidelines
I make reference to a "Vision Statement" which I am still in the process
of drafting up. I'm hoping to have it ready for review sometime next
week.
I'm pasting the text here for the CVS Commit Guidelines but without
formatting, markup or links:
============================================================
CVS Commit Guidelines
In order to achieve our Vision Statement, the AOLserver Project solicits
contributions from any interested party. There are a limited number of
[AOLserver Project Members] for the AOLserver Project hosted at
SourceForge who have access to accept and commit these contributions,
and this document outlines the general policies governing this activity.
------------------------------------------------------------
1. Everyone who has CVS commit access, has CVS commit access.
Obviously true, but what does this really mean? It means that if you
were given CVS commit access, most likely it was intentional and the
interpretation of that action should be obvious: it has been
acknowledged that the project wishes you to commit changes to the
project.
2. Who grants CVS commit access?
While there are currently a number of Project Administrators, any of
whom technically can grant others CVS commit access, the current Project
Owner should be the only person to grant new members CVS commit access.
There is no guidelines for deciding who to grant and not grant such
access; the decision is solely left to the discretion of the current
Project Owner.
3. I have CVS commit access and someone has contributed a patch which
fixes a bug. Should I just go and merge it in and commit?
This is probably the hardest question to answer. Use the answer here as
only a limited guideline to help you decide, and not as the
authoritative rules governing this decision.
In the case of a patch which fixes a bug, ensure that the bug is
documented by being filed in the [SourceForge Bug Tracker] first. This
gives others a chance to investigate the bug and comment on it. The
contributed patch may fix the bug, but there may be other solutions that
are better and should be considered. Sometimes, the fix is trivial: it's
still useful to have the bug documented for future review of past
changes and bug fixes.
It's important that changes do not simply get merged in and committed
without testing. If you wish to commit a change, do not do so unless
you're also willing to commit the necessary time and resources necessary
to test it. Sometimes, this just isn't feasible: use your best
judgement, but it should generally be an exception and not the rule that
changes get committed untested.
Finally, if you are a Project Admin., assign the bug to yourself to
indicate that you're taking ownership of it. Otherwise, append a comment
indicating that you wish to do so and request the bug be assigned to
you. Once you are owner of the bug, proceed with merging in the change
and testing to ensure the bug has been fixed. (Once a regression test
suite has been developed, ensure all regression tests pass as well.)
After committing the change, append a note to the bug indicating that
you did apply the change and that you committed it.
4. What about feature enhancement patches? I think the feature is
desirable, can I commit the change?
Like #3 above, this is only a suggestion and ultimately the decision
should be made using your best judgement. However, here are some
guidelines you may want to consider:
* Every line of code added increases the overall maintenance burden of
AOLserver. While perceived to be small in some cases, there is a
non-zero cost, however small it might be. Just because a feature has
value does not mean it's valuable enough to be added to AOLserver.
* A feature that seems easy to implement today may make adding other new
features or changing existing features more difficult tomorrow.
* Once a feature is implemented a particular way and people begin to use
it, especially once they've deployed it into a production environment,
it is very important to carefully maintain backwards compatibility. An
inadequately thought out implementation may result in the need to
break backwards compatibility. It is worth deferring adding such a
feature until the design has clear signs of longevity rather than
adding it in an incomplete state and then having people rely on it.
* Every new feature is an opportunity to add new bugs. Is this feature
worth the risk?
* Does this feature help bring AOLserver closer to meeting its intended
goals from the Vision Statement?
* Am I responsible for defending my decision to commit this change with
my peers? If the feature turns out indeed have negative impact, do I
feel comfortable with the responsibility for causing it? Do I have the
time to make the necessary corrections to make things right and
support my decision?
* Do I feel this feature has been adequately discussed with my peers?
Have I given adequate consideration to all the reasons why the change
request shouldn't be accepted? If people are voicing strong opinions
against the change, do I really understand why?
If you still feel the feature should be added, then remember #1.
Generally, follow a similar procedure as outlined in #3: ensure an RFE
has been filed in the [SourceForge Feature Request Tracker] for people
to discuss the request; assign the RFE to yourself or append a comment
requesting a Project Admin. do so; merge the change in and test as much
as you can; (once an automated test framework is in place, ensure you
implement adequate tests to cover the new feature); commit your change
and append a note to the RFE indicating you did so.
5. I hate to admit it, but I don't want CVS access anymore. What do I do?
Inform the current Project Owner and the access will be removed.
--------------------------------------------------------------------------------
Last Updated: 18 Aug 2004, 22:39 GMT
============================================================
--
Dossy Shiobara mail: [EMAIL PROTECTED]
Panoptic Computer Network web: http://www.panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of
your email blank.
