Forum OpenACS Q&A: Re: RFC: Guidelines for what should and should not be TIPped

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?
Collapse
Posted by Joel Aufrecht on
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.