Information
We are currently investigating an issue with the editor of some pages. Please save your work and avoid to create new pages until this banner is gone.
How does the ACS team work?
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
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.
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.
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.
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
Same as Developer's duties plus
Here a some of the tools the ACS Developers are using.
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
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.
In addition to the coding standards defined by SE for all of ALMA, some other standards have been established.
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.
For each release there is a release notes document which shall be updated by the developer.
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.
When is new software considered "ready"?
-- HeikoSommer - 09 Nov 2006