Problem
How does the ACS team work?
Solution
This somewhat different FAQ is used to document the existing work culture and procedures, with the goal of better sharing and improving them. It is mostly meant for ACS team members, but may also serve for exchanges of ideas between subsystems later.
TOC
Who is responsible for what?
ACS developers are assigned a set of modules to maintain and develop. These assignments are not exclusive, so you could be tasked to work on any given module as necessary.
Developer's Regular duties
Daily activities
Check the Build ReportsThe ACS software is built nightly by the Nightly Reporting System (NRS), the VMWare Factory, and on te22 and te78.
Check the SPRsNew reports about your modules can be found in Remedy, JIRA or your actions.
Before going homeAlways check that you have stopped all ACS processes for the development servers (te1, te22, te78....)These machines are rebuilt every night with the HEAD of svn and modular tests are run.Leaving ACS processes running, might interfere with these built and test procedures.
Weekly activities
Attend the Monday ACS Team meetingsA conference call is held every Monday at 16:30 CET (GMT+1).
Submit your Weekly ReportIt should containWhat did you do last week?What will you do this week?How much time did you spend on each type of work?
Check your ActionsUpdate the status as necessary.
Monthly Activities
Update availability estimatesGive the number of days you will be available for ACS work for the next monthUpdate the ALMA monthly reportadd your our information to the MonthlyLeadsMeetings
Team Lead Regular duties
Same as Developer's duties plus
Monthly activities
- Sunsystem Monthly Report Preparation in MonthlyLeadsMeetings
- Attend Monthly Leads Meeting
Our Tools
Here a some of the tools the ACS Developers are using.
Team Communication
- Yahoo! Messenger for quick messages between team members
- Skype for conference calls
Development Hardware
WorkstationsACS Developers generally use Intel-based PCs running either Windows or Linux. The actual configuration depends on the developer's preferences but, at a minimum, they should have Eclipse or Emacs installed. Some developers work in a VMWare virtual machine. This configuration is portable between different machines and can be useful in testing situations.
ServersWe have several machines assigned for its own development purposes. They are named texx.hq.eso.org where xx is the number of the machine. Some specific purpose machines are:te22.hq.eso.org: complete ACS with RTAI build environment for RHEL 5te78.hq.eso.org: complete ACS build environment for RHEL 4te1.hq.eso.org: complete ACS build environment for RH5te4.hq.eso.org: file server for Windows-based development machines
Software Engineering
Source Revision ControlALMA software development uses Subversion (SVN) to manage the source tree.
Problem TrackingCurrently, JIRA is used to manage the SPRs.
Automated Build SystemThe Nightly Build System checks out, builds and tests the HEAD revision. This system is maintained by the ALMA SE group.
Software Quality AnalysisThe Nightly Build System also runs checks for adherence to coding standards, naming conventions and test coverage.
Development Cycle
Coding and Testing
Source Tree Organization
Coding standards
In addition to the coding standards defined by SE for all of ALMA, some other standards have been established.
Exception handling
Logging
- Logging of errors for which an exception is thrown:
In principle it is the responsibility of the client (e.g. subsystem component) to deal with exception thrown by ACS, which often will involve logging the exception with its entire stack trace. However this often does not happen, and therefore ACS code must also log something. To avoid excessive logging, ACS must log such exceptions at level DEBUG or lower. This is a compromise that facilitates system debugging, but avoids bad side effects for an operational system where DEBUG level logs will be discarded.
Change Commitment
Develop against the HEAD revision or maintenance branch onlyAvoid creating private branches because it makes integration more difficult.Keep the system stableYou should not break the build. If it is necessary to break the build, let the rest of the team know why you are doing it and when you will fix it.Keep the changes smallIf you have to make a large change, try to break it into smaller pieces.Commit OftenLong development runs tend to create integration problems later on. It is easier to keep synchronized the with others if commits are made periodically.Use developer tags if you wishThe label form is up to you.Two weeks before a releasethe critical modules (like the Makefile) should be archived.The week before a releaseonly patches needed for the release should be archived.
Release
For each release there is a release notes document which shall be updated by the developer.
Frequency
Major ReleasesOnce per year we will release ACS with a new integer version number. To allow for a clean evolution of ACS, features previously declared as "deprecated" can be removed.Minor ReleasesAs required, minor releases may be made. These releases will increment the fractional version number and must be backward compatible with the previous release. If an important bugfix requires an incompatibility, which could happen if ACS has to move to a newer version of some 3rd party tool, it will be documented appropriately.
Criteria
When is new software considered "ready"?
-- HeikoSommer - 09 Nov 2006