Last modified 9 years ago
Last modified on 01/17/12 17:30:06
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)
- EMI wants to create metrics on the time needed for transitions:
- 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
Attachments
-
BugStates_v4.jpg
(35.3 KB) -
added by bernardt 10 years ago.
EMI Bugtracking State Diagram