Introduction

This page describes the duties, and points to some useful documentation, for release coordinators of the ATLAS offline software. Note, several sections are closely based on corresponding sections in TriggerReleaseCoordinationProcedures, which is also a useful reference.

Overview

As release coordinator, you should:

  • Collect, validate, and accept new tags, using TagCollector (liasing where appropriate with trigger release coordinators, PROC, and project coordinators).
  • Check the status of nightly builds, and corresponding ATN tests, on Nicos
  • Read the reports of the reco expert shifter for your release, and try to keep up-to-date with the status of important bugs in Savannah
  • Phone into the tag approval meeting (currently Monday 4pm and Thursday 6pm)
  • When appropriate, send an email to atlas.release@cernNOSPAMNOSPAMPLEASE.ch to request the building of a new release.

As part of these duties, it is also important to be aware of:

  • The sequence of releases through which accepted tags are "swept".
  • The deadlines for validating and accepting tags for the nightly builds.

Release coordinator rights

To be set up for a new release coordinator.

1 Recipe to set up AtlasProduction RC rights: In TC, Browse, AtlasProduction (browse), click on latest cache. DefineAsReleaseCoordinator. If needed also undefined the previous person. That's it. Propagation to future releases is done for you. 2 Recipe to set up overall RC rights, e.g. for bugfix/merge release: grants rights as above for AtlasOffline (tick apply to dependencies)

Procedures for bugfix/merge release

Bugfix/merge releases can be recognised by their 3-digit release number ending in a number greater than zero, e.g. 15.5.1.

The release has the full portfolio of Atlas projects: DetCommon, AtlasCore, AtlasEvent, AtlasConditions, AtlasReconstruction, AtlasSimulation, AtlasTrigger, AtlasAnalsis, and AtlasOffline. The main purposes of the bugfix/merge release are:

  • sweep tags from caches (AtlasProduction, AtlasP1HLT) to merge them and maintain coherence
  • provide a new base release to move to when a cache gets too large (nominally 50 packages)
  • provide a mechanism to accept bug fixes that are technically unsuitable for a cache, e.g. requiring many client rebuilds.

The main role of the release coordinator in a bugfix/merge is therefore:

  • work closely with the designated trigger bugfix release coordinator (currently Corrine Mills), and the Tier0 coordinators, see below.)
  • proactively monitor the impact of tag updates and swept bundles from any cache w.r.t. ATN
  • identify and request postponement/roll back of tags that break tests
  • monitor and file bug reports in Savannah
  • manage tag approval process for tags that are submitted, according to criteria and procedures we will agree.
  • assist developers by explaining the tag submission process and giving feedback on their requests
  • delivery of a new base release with no problems and understood changes w.r.t. the AtlasProduction cache
  • check status and deal with tags at least once per day before the deadline.
  • join the twice-weekly tag approval phone meetings (currently Monday 16:30 and Thursday 18:00, lasting 30 mins). A reminder will be sent via atlas-sw-tagapprove@cernNOSPAMPLEASE.ch.

Daily reports on ATN & RTT test results will be sent by the reco shifter. Communicate with that shifter and the validation coordinator to tailor their reports (content and time) to your needs. You should however proactively monitor test results yourself. You should try to correlate any problems you find with new tags and request roll-back of problematic tags.

Procedures for a development release

Development releases can be recognised by their 3-digit release number, e.g. 15.1.0, 16.0.0

The release is split into projects. Each one has its own release coordinator, nightly build, and tag collector page.

The general role and technical procedures are described here:

There will also be posts explaining the current release policy in hn-atlas-SW-developers-announce egroup and to the tag approval mailing list.

  • File bugs in Savannah for anything that needs fixing so it is not forgotten. Close the bug when the fix is in the bugfix/dev nightly and any relevant caches. Keep an eye on open bugs to make sure they are progressing.
  • Special migration ('MIG') nightlies are used to perform disruptive migrations. These have to be merged into the dev or bugfix release when ready.
    • You should be informed about these in the bi-weekly tag approval meetings
    • If one is soon to be merged back into dev nightlies, check trigger tests are passing ok and give feedback
  • For trigger migrations you should help plan any mergers in consultation with the other release coordinators, to fit in with the release schedule.
  • You may have to submit bundles of tags or compile bundles from already submitted tags on behalf of trigger developers.
  • Caches
    • Find out which are the related caches to this release.
    • Also consider if tags should be submitted to the AtlasProduction cache too.
  • Check status and deal with tags at least once per day before the deadline.
  • Join the twice-weekly tag approval phone meetings (currently Monday 16:00, Thursday 18:00, typically last 30 mins). A reminder will be sent via atlas-sw-tagapprove@cernNOSPAMPLEASE.ch.

Procedures for production cache

A production cache is identified by a 4th digit in the release number, e.g. 16.6.9.8. Your role is to manage the tags and follow bug fixes in this cache. All the tags are submitted to a special patch project (AtlasProduction) rather than the original 10 or so projects like AtlasTrigger, AtlasSimulation, AtlasReconstruction.

The general role and the technical procedures are described here:

Your main responsibilities are:

  • to vet and test tags that are submitted for the production cache
    • check if they satisfy the criteria to be included, i.e. the policy of significant bug fixes only and the technical constraints of the cache - cxx and python changes ok, header changes where the header is used by another package are not ok.
    • check in the tag collector if there any pending tags that you have asked to accept. Follow-up with the cache coordinator why it is still pending. To check the tag request for the production cache use the "Power User" view in the tag collector.
  • act as a contact point for developers and assist them with tag submission to the cache if required
  • pro-actively manage bugs in Savannah related to the cache and actively chase ones that in need to be solved before a cache is built, according to your judgement and input from others.

Handling tags

  • Tags are managed via the Tag Collector.
  • The AtlasProduction cache is now used for both production and Tier0.
  • It is open to all developers to submit tags. discuss it on atlas-trig-relcoord@cernNOSPAMPLEASE.ch.
    • On the tag approval page for the relevant AtlasProduction release, tick the 'Support request' or 'Remove supported flag' box in the 'Your Decision' column.
    • You can also write more detailed support/advice to the Production, Tier0 and Reprocessing coordinators using the 'Comment to append' box in the 'Edit request' column.

Bug handling:

  • Make sure all Tier0 bugs that enter Savannah have the 'Tier0' option set to 'Affected' and then later to 'Fixed' when the problem is solved.
  • But please don't set it fixed/closed overall until all 'affected' have become fixed.

Release coordinator responsibilities

Tag sweeping

Sometimes it is necessary to manually sweep tags between different projects. In the following examples, the official sweeping script is being used. By default it only prints the tags of the sweep. Add --exec, --user and --pass to the commands to create the sweeping bundle in TagCollector.

Sweep from AtlasCAFHLT to AtlasP1HLT

/afs/cern.ch/user/a/alibrari/scripts/tags_push_back.sh --from 15.5.6.9.1 --proj AtlasCAFHLT --dest 15.5.6.10 --pdest AtlasP1HLT --branch
The --branch option will include branch tags in the sweep, which is most likely what you want to do in this case

Checks on nightly builds.

As mentioned above, several sets of tests are run on nightly builds. Reco shifters will look at these, but it is also useful for release coordinators to check them regularly.

ATN tests

RTT tests

TCT

Tools

-- NickBarlow2 - 07-Jun-2010

Edit | Attach | Watch | Print version | History: r4 < r3 < r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r4 - 2010-08-11 - NickBarlow2
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Sandbox All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback