P4DTI issue job000757

TitleIssue script doesn't segregate TeamTrack jobs
Assigned userDavid Jones
DescriptionThe 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.
AnalysisThis 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

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

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 foundinspection
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 in2.0.0
Introduced in2.0.0
Created byNick Barnes
Created on2003-08-05 17:26:02
Last modified byGareth Rees
Last modified on2010-10-07 12:07:30
History2003-08-05 NB Created.
2003-08-20 DRJ Closed.