Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

EGI-InSPIRE:Feedback from M. Drescher

From EGIWiki
Jump to navigation Jump to search

General Comments

  • I like the idea of integrating RT and GGUS in such a way that the technology provider integrates with GGUS only (by interface or endorsement).
  • I like the idea of automatic ticket synchronisation between GGUS and RT, i.e.
    • GGUS -> RT upon ticket creation
    • RT -> GGUS upon ticket modification (until the RT ticket resolved, which closes the ticket in GGUS)

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:

Status

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

Allowed values:

  • new - Ticket is created, but not assigned yet. Initial state once synched from GGUS.
  • open - Ticket is assigned to a person or group (does that feature exist in RT?) and work is undertaken
  • rejected - The ticket is faulty, invalid, duplicate or otherwise something that must not inflict work upon potential assignees.
  • resolved - The request has been resolved with an outcome (and auditable trace of documentation etc.!). Causes the ticket to be synchronized back to GGUS.
  • deleted - does not apply
  • stalled - does not apply(?)

Outcome

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

Allowed values:

  • Unverified - The pertinent release has not yet been verified against the Quality Criteria (QC), but is available for that in the "Unverified" repository.
  • In verification - The release is under assessment against the QC.
  • Waiting for response - The QC verification officer is waiting for a response from the technology provider for one or more minor, uncritical issues of the package (missing documentation link, for example). Note that the state may oscillate between "In verification" and "Waiting for response". Each state change is recorded hence available for metrics.
  • StageRollout - The release has been successfully verified, and a link to the final verification report in the document database has been provided in the ticket.
  • Accepted - The EA have tested the release in their production infrastructure (open issue what is the testing process? Is this anywhere formalised?), and written reports of each EA were aggregated and consolidated by the assigned release manager. The consolidated report is stored in the document database with references to the individual EA reports. A link to the aggregated report is given in the ticket. The aggregated report also MUST report any warnings issued by any EA during the StageRollout phase of the release.
  • Rejected - The EA have tested the release in their production infrastructure. Same reporting requirements as for "Accepted" apply. A release may also fail the QC verification. In that case the report must be present reasoning about the failure of the verification.

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).



-- to be continued, running out of time --