| Title | Issue script doesn't segregate TeamTrack jobs |
| Status | closed |
| Priority | essential |
| Assigned user | David Jones |
| Organization | Ravenbrook |
| Description | The release notes have a "What's New" section automatically generated by the issue script (see the release build procedure [4] for instructions on this). For 2.0.0, this included all outstanding TeamTrack integration jobs, because support for the TeamTrack integration moved to TeamShare. But these jobs were all intermingled with the other jobs in a confusing manner. They should be in a separate section or at least separated somehow from the others. |
| Analysis | This is Perforce job job011360. See the 2.0.0 release notes [3] to understand the detail of the problem. Maybe we need a new status for our jobs (not_our_problem_any_more?!). Then the issue script could automatically sort them out. Hmm. What is the purpose of release notes? Perhaps to inform the user or potential user of the impact of using this release of the software, particularly compared to some other release of the same software. The interesting thing about a release is: - it's intended behaviour (that is, what requirements are intended to be met) - it's actual behaviour in so far as that impacts the intended behaviour. In general release notes should have an item for: - any change in the requirements that are intended to be met: - new requirements - dropping old requirements that once were met - bug fixes (changes in behaviour that impact a requirement that is intended to be met) If we drop a requirement and that requirement was one that we never met then that can't affect the intention of any release, therefore it need not be mentioned in the release notes. Indeed, it is confusing to mention it in the release notes. If in the past some bug was fixed that affected a requirement that is now dropped then this shouldn't get mentioned in the release, it's completely unimportant. In terms of jobs the following categories can be distinguished: - A. fixed jobs that correspond to requirements that once were not met and now are met. - B. fixed jobs (Status=closed) that correspond to requirements that once were met and now are no longer required. - C. jobs that were never fixed and are no longer required. - D. jobs that were fixed that correspond to bugs against a requirement that is no longer required. - E. fixed jobs that correspond to bug fixes. - F. jobs that are not fixed and are still required. It's possible there are other categories as well. The only one I can think of is where a requirement is deliberately dropped even though it is still a requirement. This might conceivably happen if meeting a Nice or Optional requirement (that was documented as being met) conflicted with meeting a Critical or Essential requirement in a new release. The release notes should consist of the additions to categories A (new requirements met), B (old requirement dropped), and E (bug fixes) that occur between 2 releases. Job states (N1, N2, N3 denote new state): A - closed B - N1 C - N2 D - N3 E - closed F - open It's not clear that N3 is required, this is the bug fixes that have been implemented but now are irrelevant because a requirement has been dropped. It might be useful for planning or admin purposes to know about these, but OTOH we could just keep them at "closed". N1 (corresponding to requirements that were once met but are no longer required) could be "dropped". N2 (corresponding to requirements that have never been met and are no longer required) could be use the already existing "suspended". According to "Rules for defects" [2] use "suspended" if it is planned not to resolve it. Which seems just fine. Does this really DTRT? What we want to see in the release notes is once change saying "TeamTrack support is dropped, perforce no longer support integrating p4dti with TeamTrack.". drj 2003-08-07 Moved jobs to suspended with: p4 fixes -c 35521 | awk '$1 != "job000627"{print $1}' | xargs p4 fix -s suspended -c 35521 (all jobs fixed by change 35521 except for job000627) The issue script does not display suspended jobs so this now outputs the right thing. drj 2003-08-20 |
| How found | inspection |
| Evidence | [1] <http://info.ravenbrook.com/mail/2003/06/13/23-20-00/0.txt>[2] < http://info.ravenbrook.com/rule/defect/>[3] < http://www.ravenbrook.com/project/p4dti/release/2.0.0/release-notes.txt>[4] < http://www.ravenbrook.com/project/p4dti/master/procedure/release-build/> |
| Observed in | 2.0.0 |
| Introduced in | 2.0.0 |
| Created by | Nick Barnes |
| Created on | 2003-08-05 17:26:02 |
| Last modified by | Gareth Rees |
| Last modified on | 2010-10-07 12:07:30 |
| History | 2003-08-05 NB Created. 2003-08-20 DRJ Closed. |