EGI-InSPIRE:Feedback from M. Drescher

From EGIWiki
Jump to: navigation, search
EGI Inspire Main page


General Comments

The following is a mix of some ideas I had, and some ideas that came from others, e.g. Kostas, Carlos, David and Ales (or Milos, or both?). So credits to all that contributed and recognise their input.

(Custom) fields

I would want to retain as many generic RT tickets as possible, simply for ease of integration and re-use:


Existing field. Takes the general RT status of the ticket.

Allowed values:


The outcome reflects both the phases of the SW release workflow, and the final outcome. Call it "Progress" if you like.

Allowed values:

QualityCriteria Verification Report

This field holds a link to the report of the QC verification process.

StageRollout Report

This field holds a link to the consolidated report summarising individual reports of all EAs.

Repository URL

Holds the currently valid URL to download the installation package. So, if the ticket has the current outcome of "StageRollout" (or equivalent), the URL should point to the package in the StageRollout repository.

Open issue - I am not sure whether releases are always a delta to a respective base package. We first need to define the scope of a release. But that is another issue (or I misunderstood).

Release metadata

This "field" I envision not really a field, but an attachment to the ticket that holds the XML data for the release referred to in this ticket. Didn't know how to describe it. For better automation the attachment should always have the same name (for example, "release.xml") and be attached throught the WS integration with GGUS (if possible).

The contents of this XML file is currently under discussion, so I will not drill into it right now.


The owner of the ticket should change from person to person, depending on the progress through the workflow. I am not a fan of assigning the ticket to a group of people, as this often leads to confusion as to who should pick up the ticket. For now I would like to see group leaders, such as the Task leaders for QC verification (TSA2.3, Carlos Fernandez), and the Task Leader for SR (TSA1.x, Mario David) as standing assignees who then delegate the work appropriately, and collect and consolidate the reports (see other custom fields, and workflow comments).


I would like a list of watchers added to the tickets to ensure proper monitoring. Again, I think the task leaders for QC verification and SR are mandatory watchers, as well as the task leader for repository management (TSA2.4, Kostas). I also would want the members of said tasks (TSA2.4 and TSA2.3 in particular) as watchers. The activity leader for SA2 (currently me, Michel) should be a mandatory watcher as well.

I am thinking of the task leader of TSA2.5, Michael, to also watch this queue as to give the DMSU a forecast on what is in the current pipeline of patches that may be rolled out into production.

I also would like to include the group of early adopters in SR to be watchers, to get their heads up for what's going on. But that needs more discussion that perhaps Mario David may lead.

Other custom fields

Regarding the custom field "RepoAction" and "RepoStatus". I do think that those lead to a synchronous implementation (which I believe does not scale well). Instead, I propose an asynchronous approach with only one status or outcome field. RT triggers the repo on certain values as described above. The repo then asynchronously takes the necessary actions, and updates the RT ticket accordingly. Particularly, if any error or exceptional situation occurs, the repo changes the Outcome to "Failed" and adds an appropriate message (does it set the ticket status to "Resolved", too?)


The workflow itself seem look fine. We have three distinct phases, i.e.

We have enough details available to flesh out all three phases, but I am still a bit unclear about the handover between all three phases. I consider those handovers very important as the responsibility for the ticket changes from one task/group to another.

Having said that, I would like to explicitly state that the group leader for the Verification Phase has the authority to change the outcome from "Unverified" to "Rejected", "Waiting for Reply" or "StageRollout". Likewise, the group leader for the StageRollout has the authority to change the ticket status from "StageRollout" to "Accepted" or "Rejected". The status of the ticket may also be changd accordingly (e.g. to "Resolved").

Personal tools