| Summary: | LTS Bugzilla | ||
|---|---|---|---|
| Product: | Working Groups | Reporter: | Andrea Ross <andrea.ross> |
| Component: | LTS | Assignee: | LTS Infrastructure Inbox <lts.infrastructure-inbox> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | andrea.ross, denis.roy, sbouchet |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Bug Depends on: | 369707 | ||
| Bug Blocks: | |||
|
Description
Andrea Ross
We'll need a mechanism such as cloning bugs to track them being propped into various LTS branches. This process also facilitates the change control board's decision process. Each bug should be linked to the original bug for traceability purposes. Thus we need meta data to track each LTS version/release of each software unit/project. Which is original? The options are: 1) The fix in the latest and greatest community code [recommended] 2) The fix in the first release it was detected. The advantages to #1: a) Less risk of a fix disappearing when people update their software because of a neglected prop. b) A chance the issue was already fixed. c) Consistency in that there's always one place to go first. d) Chance control processes have one place to look for input as to which fixes need a decision whether to prop or not. The advantages to #2: a) Quicker turn around to a fix being available in the field deployed version of the software. Moving to the Working Groups section. LTS is no longer active. |