Draft 6 Reviewers Notes = Please Read

These notes accompany Draft 6. Draft 6 is the second recirculation of the complete draft, also known as the Sanity Review draft. These notes should be read prior to reviewing the document set.

The review period for Draft 6 commences April 17th 2001 and completes May 21st 2001. A plenary meeting is being held in the week of May 29th.

Since Draft 5 passed The Open Group Fasttrack ballot, and the IEEE ballot the document is now effectively complete. The main purpose of the draft 6 recirculation is an editorial review to ensure that changes arising from the Draft 5 review have been applied as the review group intended. Thus, for this recirculation, we are now in a strict narrowing down process. Objections can only be accepted on certain sections of the document.

  1. An objection will only be accepted if it supports an objection from the draft 5 review for which no changes were made to the draft, or if it concerns a technical change that was made between draft 5 and draft 6.

    To assist in determining these differences, changes between Draft 5 and Draft 6 are denoted with change bars. An objection to a change must relate only to the material change and not be for a different matter at the same line (note that many of the change bars are for shallification and other editorial matters).

    If possible when raising an objection it would be helpful for reviewers to include a reference to the corresponding Enhancement Request Number (ERN) from the Draft 5 review change requests, if known.

  2. You may raise a comment on any part of the document
  3. You may raise an editorial comment on any part of the document

Summary of the Changes

Detailed change history is given on each manual page. A summary of the changes included in this draft is as follows:

  1. In order to facilitate the IEEE electronic ballot process, page numbering for this draft is sequential through the volume set.
  2. Application of the Enhancement Requests from the Draft 5 review period.
  3. Application of IEEE PASC 1003.1 and 1003.2 interpretations
  4. Application of The Open Group Base Working Group resolutions.
  5. Where open issues exist a reviewers note is placed within the text.
  6. STDOUT/FILES sections for utilities
    Reviewers are asked to review the STDOUT and FILES sections for each of the utilities for completeness and correctness (this request was also here for Draft 5)
  7. The pthread_setschedprio() function is new (as per IEEE PASC Interpretation 1003.1 #96).
  8. The readv() and writev() functions are broken out onto their own reference pages for clarity.
  9. Pointer pages
    Pointer pages for all functions are included in XSH (since draft 5). These will be rationalized at the proof stage.
  10. Change Bars
    A revised change bar tool has been used to generate this draft. Some editorial changes have not been change bar'd (although this does not apply to all the volumes), including:
    • file name -> filename, path name -> pathname
    • The _SC_ list of variables was moved within unistd.h (see XBD ERN 380)

Change Request Reports

A set of change request reports (Ballot resolution reports) is available to accompany the draft. There is a separate report for each volume of the specification. Each has a summary table followed by detailed text giving the problem report together with the disposition.

There are four dispositions:

  1. Accept - we agreed with the problem and made the suggested change as suggested
  2. Accept as marked - we agreed with the problem and made an alternate change to resolve it.
  3. Duplicate - this request is a duplicate of another request, please see the other request for the resolution
  4. Reject - we did not agree with the problem statement. There are various common categories for rejection which occur as below, other reasons may also be stated.
    • R1.Reject: The requirement is from a base document and to change it is out of scope. Bringing it in scope would require an interpretation, corrigenda or resolution from the appropriate body.
    • R2. Reject: this interface is not a candidate for Legacy, the list of Legacy interfaces was considered in March 1999 and is now final. It is widely used in historic practise and deprecating this interface would break the contract with the application developer.
    • R3. Reject: we cannot see the problem at the referenced lines, as such this comment is non-responsive.
    • R4: Reject: no action is specified in the aardvark comment.
    • R5: Reject; The review team disagrees with the problem statement because.. ... {further rationale needed}
    • R6: Reject: The review team believes that accepting the proposed change would decrease consensus.
    • R7: Reject; this is out of scope.
IEEE ballots are denoted specifically by the words ieee.balloter or IEEE.BALLOTER. Individuals are identified by their email addresses in the ERN. All balloters have been notified of the availability of these reports.

Where a response is other than an ACCEPT the disposition is documented in the header text section of the ERN

Known problems