RfC and Bugtracking

Implications

Bugmapping has the following implications for us (these are not all yet):

• Facts concerning RT:
  • EMI wants to create metrics on the time needed for transitions:
    • Open to Accepted
    • Accepted to Fixed
    • Fixed to Verified
  • Differentiation between code changes / other changes (documentation, general questions)
  • Assign bugs to EMI components (dcap, srmclient, server, voms2gplazma)

• For Component Releases (CR) Savannah needs to have:
  • List of packages affected: by the change and the URL from where they can be downloaded.
  • Release Notes: non-technical text written in good english giving an overview of the change introduced by the packages. The text should be prepared by the PT responsible for the component. It should contain the following structure:
    • What's new: Brief description of the main changes, both new features and bug fixes.
    • Installation and configuration: More details on installation and configuration stating very clearly if the service must be reconfigured and/or restarted.
    • Know issues: Known issues present in the release, possibly with a workaround.
  • List of RfC (bug/feature): that entered this release (How do we do that? Maybe: Writing script that goes through SVN changelogs or every bugfix gets assigned to EMI release)
  • Test report: Link to the test report where the test results of the executed tests are included.
  • Documentation: Link to the relevant documentation (user guides, troubleshooting guides, etc...)
  • Known Issues: List of known issues associated with the release.
  • Changelog: For each of the released packages, a changelog containing the developer's comments associated with each change should be included.

Open Questions

• How do we track the affected packages of a CR
• How Do we track the RfCs? that entered

EMI Bugtracking State Diagram

Mapping Table EMI bugtracking states --> dCache RT states

State ID	EMI state/transition definiton	EMI state/transition	dCache RT state ransition	dCache state/transition Definition	TimeStamp?
1	The RfC is opened after all the necessary clarifications have been made. This includes discussion in a GGUS ticket to understand if there's an actual problem and an RfC addressing the problem should be opened; internal discussions within the PT after a defect has been found or after an improvement has been proposed; etc.	Open	new	Indicating that a ticket has just been created and has not been read by the support team yet.	Created
The clarification is complete and the RfC is accepted to be implemented.		Open-->Accepted	new-->open
2	The RfC can be implemented by the PT. This state triggers the implementation of the RfC within the PT.	Accepted	open	Indicating that a ticket has been read and accepted by the support team and assigned to a developer.	We need a new timestamp stating when the ticket changed to this state (later refered to as: new timestamp)
The clarification is complete and it's been decided not to implement the RfC.		Open-->Rejected	new-->rejected
3	The RfC won't be implemented and the PT should explain why it has been rejected.	Rejected	rejected	Indicating that the ticket was not accepted by the support team (for example: an info for us, but not a support ticket, or an issue for SysAdmins? , not for us, we"re only on CC). The ticket will remain recorded in the system.	new timestamp
The implementation of the RfC has finished, that is, the code has been committed, it has been built and packages are ready to be tested.		Accepted-->Fixed	open-->resolved
4	A set of packages are ready to be tested.This state triggers the certification of the RfC within the PT.	Fixed	resolved	Indicating that work on a ticket has been completed.	new timestamp, this is where it should vanish from the developers view in RT and only be visible to the tester
The PT is not able to certify the RfC.		Fixed-->Not Certified
5	The RfC can't be certified and the PT should explain why.	Not Certified	not_certified	Not sufficient resources	new timestamp
	The PT can certify the RfC and after doing the actual certification, all the tests are successful.	Fixed-->Certified
	The PT can certify the RfC and after doing the actual certification, the tests have failed.	Fixed-->Accepted
	The release manager makes sure all the bugs associated to a certain component release are closed when the component release is released to the EMI production repository.	Certified-->Closed, Not Certified-->Closed
6	The RfC has succesfully passed certification. The PT should include the certification report.	Certified	certified	We have tested the bugfix in our testbed.	new timestamp
7	The bug fix is now available in the EMI production repository.	Closed	closed		new timestamp

States that are not mapped

dCache RT state	Definition
stalled	Indicating that a ticket cannot be worked on for now due to some reasons, but will be opened again when someone adds a comment or reply.
deleted	Indicating that a ticket should not have been in the system and is being removed (for example: spam).

RT Changes

Bjoern said changes can be implemented in RT. Adding states is no problem, the properties described below can be added without a problem and the timestamps might be achieved through custom fields.

These are the changes that need to be made in RT other than the ones shown in the table above. The following properties will be needed:

• new property Product {default:client, server} (be aware that this is sometimes called component within the dCache, which is wrong by definition of EMI)
• new property Ticket-Type {code, docu, advice, ..., other}

A problem could be that a ticket might concern multiple products and might concern code and docu at the same time.

Automating Things

Concerning