Getting Started

Documentation

Glish

Learn More

Programming

Contact Us

Version 1.9 Build 643

News	FAQ
Search	Home

Result

Refresh and clarify the current check-in policy (revised aips2-workers #2240).

• Maintaining the stability of daily is a high priority for everyone in the project. Breaking daily affects the work of a large number of people.

• Maintaining the stability of weekly is essential. Breaking weekly is disastrous for the work of a large number of people. Our goal should be that every weekly can be marked as stable.

• Checkins of changes to existing code should be made with the above two goals in mind.

• Changes to code that is used by others must be well-tested on the project compiler before checkin, including running the associated assay() tests. Checkin of purely developmental code is less crucial but still good habits should be followed.

• All checkins except simple ones, and bug fixes should be done early in the week. Early means with two more of your inhales to get it right before the final weekly.

• If you have a substantial change that will require more than a week to test, this should be explictly scheduled in consultation with the project management so that it can be coordinated across the consortium.

• All development sites should be running a daily using the project compiler.