EMI SA2 Change Management Guidelines Discussion

Thursday 2 Sept 2010, 10:00 → 12:00 Europe/Zurich

CERN

Phone conference to re-discuss the Change Management Guidelines described in: https://twiki.cern.ch/twiki/bin/view/EMI/EmiSa2ChangeManagementGuidelines

Minutes of the Change Management Guidelines Phone Conference on 02.09.2010

Participants

dCache: Owen and Antje

Unicore: Bernd

ARC: Oaxana and Anders

SA2: Jozef, Eamonn, Gianni, Maria, Alberto

SA1: Cristina

JRA1: Zdenek

Introduction

Maria proposes to use the twiki page:

https://twiki.cern.ch/twiki/bin/view/EMI/EmiSa2ChangeManagementGuidelines

as the main material for the discussion. She proposes to discuss only the sections about:

• Request for Change (RfC)
• Change status
• Release Candidate (RC)

This is because the other sections are coming from the Software Maintenance and Support deliverable written by Francesco, who hasn't joined the phone conference because he is on holidays.

Owen makes some remarks about the current change status defined in the twiki and Maria reminds him that there will be time to discuss about that. First they will go through the contents of the RfC.

 

Request for Change

Maria summarises the proposal presented in the twiki and asks for feedback. Owen says they don't have all the proposed fields and that in fact he's missing some fields that they consider important for dCache like patch reference and person reviewing the code. Maria agrees that new fields can be added. Maria suggests to better go through the proposed fields and give more specific feedback:

• Uniq ID: OK for everybody.
• Title: OK for everybody.
• Longer Description: OK for everybody.
• Affected SW components: people suggest it's better per area or SW category. It's OK for Unicore and ARC but dCache needs to discuss this internally since they don't provide this at the moment.

A discussion is started by Owen who explains that in dCache they have a bug tracker (RT) and then a Change Management tool (Review Board) so some of the proposed fields doesn't make sense to him in the bug tracker. Maria explains that the goal of the discussion is to agree whether the proposed fields are useful and should be added in the bug trackers.

• Priority:
  
  • dCache doesn't have this at the moment. They will discuss internally and report back.
  • Unicore has priorities from 1 (lowest) to 9 (highest)
  • ARC from 1 (highest) to 5 (lowest).

It's discussed how to map for these priorities to the ones in the twiki (Immediate, High, Medium, Low). Maria will present the results in the twiki.

• Defect vs Feature:
  
  • dCache uses a separate tracker for requests coming from users (RT) and features (TRAC).
  • Unicore uses a separate tracker for bugs and features, with similar fields (Sourceforge).
  • ARC has 8 severity levels (i.e. blocker, feature request) but it uses the same tracker  (Bugzilla).
• Detected Area: The justification for this field is presented by Maria and Alberto who give examples why it's a useful field. It will be used to get statistics about how many bugs are discovered in development/certification and how many are discovered by the users. Alberto reminds everybody that GGUS should be the unique entry point to communicate with EMI users. He invites the different middlewares to attend the discussions on User Support. All the middlewares express their lack of interest for this field, which is not present in their trackers.
  • dCache: GGUS tickets for dCache automatically create a bug in RT. They can find out the detection area by checking who is the originator of the bug.
  • Unicore: They don't have this field and they can't add new fields.
  • ARC: they don't have this field but they can add new fields. However they will only exist in new bugs; that is, bugs submitted between May 1 and whenever this field is introduced, will not have this attribute. They are not convinced that this particular attribute is important for software development.

A discussion is started by Unicore stating that all the requested information could be provided as free text in the description of the bug and then use some scripts to extract each specific information. There's no point in changing their tracking tools only for EMI since they have other users. Everybody seems to agree with this approach and it's agreed that the requested information in the RfC is OK and can be provided in that way by each middleware.

We don't finish the list (EMI major release + Verified bug) but Alberto suggests to present the results of the comparison we've just made to the PEB and see whether they agree to have different formats with the consequences of it (maybe some metrics can't be provided, etc).

Change States

Each middleware explains how they map to the proposed Change States. Only dCache is able of change states in their tracking tool.

• dCache: They don't have the state 'Accepted'. They close the bug when the fix is committed to CVS. They don't track it anymore after it. Then they do the release management part in the Review Board.
• Unicore: It's similar until the part where it's fixed when the bug is then closed. No verification/release part.
• ARC: They don't have 'In progress'. They have 'Reopen'. They close the bug when it's released to production.

This mapping will be presented to PEB. It has to be understood how to generate metrics if tracking tools are going ro define different states.

 

Release candidate

Everybody agrees with the requested information. Cristina suggests that each middleware keeps on using the same method to communicate a new release and that she will fill in the corresponding object in Jira.

 

Actions after the meeting

• Maria to present the mappings on the twiki.
• Alberto to present the mappings to PEB.
• Owen to discuss internally and send conclusions to the list.