Tracking tools
This wiki will help the IT-SDC-MI group decide the structure that should be used for the tracking tools
Basic assumption:
- Jira will be used to keep track of development and deployment
- Jira will be open to end users to see the status and comment
- GGUS/SNOW will be supported
The main discussion now is to decide if there should be a single project (with each application as a different component), or different projects per application. Other alternatives (like one project per rpm, or one project per category) have already been discussed and discarded (see
Tracking Tools Presentation.
Jira concepts:
- Category: Project belong to a category. This is used only for the initial page. Current categories: ATLAS, ATLAS ADQ, IT Databases, IT Services, IT infrastructure
- Project:: Basic unit of jira. Roles, versions, notifications and workflows are defined at the project level. Current projects: AI, AI Monitoring, ATLAS simulation, Big Brother, CERN mobile web pages...
- Component: Projects can be divided into components. Examples: for AI has 45 component (cli, boson, archive, apollo...), GEANT has 3 components (framework, physics, navigation), lcgutils has 12 components (davix, gfal 1.0. gfal 2.0)
- Version: Originally, assignated to a project. Several projects put in the version the component name to which it applies
IT-SDC-MI applications
This table contains the applications that will be considered, and their current leader
Application |
Project leader |
FTS Dashboard |
A.Beche |
XRootD Dashboard (FAX, AAA) |
A.Beche |
WLCG Transfers Dashboard |
A.Beche |
ATLAS DDM Dashboard |
David |
xbrowse |
David |
SiteView |
Eddie |
WLCG GoogleEarth Dashboard |
Eddie |
ATLAS DDM Accounting |
Eddie |
ATLAS Historical Views |
Eddie |
CMS Historical Views |
Eddie |
ATLAS Production Task Monitoring |
Eddie |
ATLAS Interactive View |
Eddie |
CMS Interactive View |
Eddie |
CMS Task Monitoring |
Eddie |
Common Framework |
Pablo |
CMS Data Popularity |
Domenico |
SAM probes |
Marian |
Use cases
This table presents several use cases, and how they will be solved in the two approaches (one single project, one project per application)
Use case |
Single Project |
Project per application |
Creation/removal of a new application |
Add/remove a new component |
Ask the jira support to create/remove a new project, replicating the workflow and basic configuration. Define developers for this application |
New member in the team |
Add the person to the project |
Add the person to all the project that are needed |
End user submits a ticket |
Submit to the project |
Either the end user submits to the appropriate project, or there is another project as an entry point. |
Create a version of an application |
Use the application name and version number (might be the version of one of the rpms) as the version |
Use a version number (might be the version of one of the rpms) |
Application developer wants finer granularity |
Use versions (or more components) |
Use components |
Issue affects several applications |
Mark it with all the components |
Duplicate ticket?? |
Issue assigned to the wrong application |
Change the component |
Change the project |
Issue notifications |
Everyone gets everything |
Issues sent only to the developers of the applications |
Migrate to the other approach |
Supposed to be easy (to be tested) |
Supposed to be easy (to be tested) |