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 ready to be 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.

6. Someone committed a change and I feel it should be backed out. Can I do it?

See #1 above. It applies in the forward direction as well as backward. Everyone who has CVS commit access, has CVS commit access -- everyone can back out anyone else's change. However, before you do back out someone else's change, you should consider the list of questions in #4 above before doing so, especially:

• Am I ready to be 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?

If you still feel it's appropriate to back out someone's change, try and discuss the reasons why you feel this way and see if others agree. Perhaps you can persuade the original committer to either back out the change, or find alternate solutions. However, if backing out the change is the correct way to proceed, then do it.