Forum OpenACS Q&A: RFC: CVS commit guidelines (was 'Guidelines for what should and should not be TIPped')

Request notifications

When should a technical change to OpenACS be approved by the TIP process, and when can someone with access make the change directly? Here is my proposal: A proposed change must be approved by TIP when
  • It changes the core data model
  • It will change the behavior of any core package in a way that affects existing code.
  • It is a non-backwards-compatible change to any core or standard package.
  • We don't have a firm list of standard packages so I propose for now that any package in dotlrn-prereq is a standard package.

    A proposed change need not be TIPped IF

    • it adds a new function to a core package in a way that
      • does not change any existing API functions
      • does not change the data model
      • has no negative impact on performance
      • OR it is a change to a non-standard package
      • Ie, adding a new API wouldn't require a TIP, and even changing an existing API function wouldn't require a TIP if the new behavior only occured if a flag were selected, and the flag is optional and off by default.

        The place where these rules fall down is ad_form, which wouldn't require a TIP by these rules but clearly would have benefitted from group review of the syntax and names before it was implemented or modified.

This clarify a lot, thanks Joel.
We are about to commit notifications in FAQs, and then in other packages, I think those not need a TIP...
TIPs need not and probably should not be the only form of technical review... Probably the ad_form ugliness that Don has complained about should have been caught via some review process less formal than a TIP?
The idea is that something like ad_form would be fleshed out in the forums, and then a proposal would be TIPped and approved. Also, I'm renaming this thread to a slightly broader topic, and adding some IRC notes.
  • Bug fixes should be tested and committed on the current release branch.
  • The current release branch is merged back to HEAD after each dot release.
  • All commits should
  • Code should not be reformatted unless it is being changed functionally, e.eg. unless when you change control flow and reindent to reflect it.
  • Database upgrade scripts should only span one release. E.g., a single script should only take a system from 2.0.0 to 2.0.1, not to 2.1.2. This also applies to development milestones - an upgrade script for 2.0.0d1 can only upgrade to 2.0.0d2 (dev 1 to dev 2). It is not necessary to have every development milestone - a script can do directly from d1 to a1 or b1.
  • Database upgrade scripts should never go to the release version, because then if a problem is found in a release candidate it cannot be addressed with another upgrade script. E.g., the last planned upgrade script for a package previously in dev 1 would be upgrade-2.0.0d1-2.0.0b1.sql, not upgrade-2.0.0d1-2.0.0.sql. We would rather use rc1 than b1, but this isn't supported yet.
  • CVS commit messages should be intelligible in the context of Changelogs. They should not refer to the files or versions.
  • CVS commit messages, and code comments, should refer to bug #, tip #, or patch # if appropriate.
  • The previous guidelines about API changes apply only to public API. Private API can be changed without TIP.