> 2.2. Ideal outcome sequence [...] > Phase 2. Deprecated second system. Integrations must refer only to > bugs in the community DTS, but bugs could be filed in either system.
This seems backwards, in that it encourages extra copying (new bugs can get filed in the legacy system, only to be copied to the new system prior to integration). The one advantage I can see for this ordering is that it allows more time for integrating Sun's, er, legacy call management software with the new DTS. Is that the idea? > E3. Differentiated, configurable messaging [...] > Messaging and notification is expected to be delivered as > electronic mail; additional protocols must be optional. Awkward wording: "must be" -> "are". (Jim noted this, too.) > E5. Interface stability and completeness > > The storage representation, command line interfaces, network > protocols, and hooks interfaces should be documented and have > some level of declared commitment. The state of the storage > representation and the operations that modify it should be well > defined, so that use with advanced file system capabilities can > be assessed for hazards. (For example, consistent use with file > system snapshot capabilities.) > > Storage representation is important because if the storage > representation changes frequently, issues might arise if > frequent upgrades of the gate and personal workspaces are > required. > > Use of the candidate DTS with advanced file system capabilities > should be defined. (For example: Can ZFS clones be used to > back up repositories? Can filesystem ACLs be used to control > access to portions of the repository?) There seem to be some copy/paste errors here. I'd delete the 2nd paragraph and merge the redundant points in the 1st and 3rd paragraphs. > E6. Standard operations and transactions > > The candidate DTS is expected to support rename and deletion > transactions at the file and directory levels. Note that a > history-preserving copy operation, followed by a delete > operation, may be considered equivalent to a rename. Copy/paste error? > The following transactions are to be assessed and documented > by the evaluating engineer: We should also list essential/desired/optional query functionality. - resolved vs unresolved - fixed in given build/release - by owner (for some definition of owner) - by priority and/or severity And speaking of essential requirements, does anyone have the requirements list from Bugtraq2/Bugster? I think it'd be useful to review it, to make sure we're not forgetting anything important. > 2.3 "Optional" requirements The original Bugtraq2 spec allowed for fairly arbitrary text as bug IDs (alphamerics plus certain special characters IIRC). This caused a big uproar in ON because it broke scripts that looked for 7-digit numeric IDs (e.g., auto URLifiers, patch README readers, putback message readers). I think there should be some requirement for easily recognized IDs, but I don't have a strong opinion on priority. As long as we can define some relatively simply regular expression for them, one that won't produce a lot of false matches, we're probably okay.[1] mike [1] I don't think that compatibility with the existing 7-digit scheme is a requirement, because a lot of the existing scripts are likely to either go away or need rewriting anyway. _______________________________________________ tools-discuss mailing list tools-discuss@opensolaris.org
