Valerie Bubb Fenwick <Valerie.Fenwick at Sun.COM> writes: > Thanks Mark & Rich, here are the proposed changes to the RTI nits > (much of the content is from Mark :) I've included complete > changed sections, elipses indicate areas I don't think need > updating - please let me know if I got it wrong. > > > SCM folks: Do you have any advice on this section? > > Advocates > ... > * Workspace checking is highly recommended, as it is easy and quick and has > prevented many problems; also, many problems which could have easily > been prevented were from workspaces which were not checked. > > I don't think we have any workspace checking scripts yet for advocates > based on mercurial, do we ? ( a question I've also asked the CRT....) > > Or would a CRT be able to safely run "hg pbchk" on someone else's > gate? (it's not generally possible to run "wx" on someone else's > gates, due to permission issues with the wx files)
It should be possible, unless the permissions on .hg/ cause similar problems. There is no wschk under Mercurial at this point, no. > I'll do the appropriate <code> markup</code> in the actual document, > but wanted to spare you all the headache of parsing an HTML document. > > One open question: How do we expect to handle bug fixes that cross > closed & open source? I believe the answer is all in one RTI, but > I figure this document would be a good place to cover it. That would be my answer, but the 3 of you have a better idea of that than I would. > Original: > http://opensolaris.org/os/community/on/crt/rti-nits/ > > SCCS Keywords > * For Nevada builds 97 and later: > - ident usage (whether #pragma, ident, or .ident) should be cleaned up > incrementally. If you touch a file, you should remove these strings. > The hg keywords (part of hg nits and hg pbchk) command should > correctly complain about this. So look for clean hg keywords output. > - Any other usage SHOULD have been cleaned up prior to the Mercurial > transition, but it's possible that some was missed. For this, please > advise the developer to remove the usage entirely. If that is an > unacceptable answer, and you deem the usage to be an interface, the > keywords may be replaced with their static expansion (or incremented > therefrom), or the user may use "hg id" or "hg log" output for > version information. The hg id command refers to the entire > repository, while the hg log command refers to a file or set of files. > * For Solaris 10 Updates and older sustaining releases: > - same text we have now (with the note on %I% being removed once 96 is > closed. Given this page is ON-specific, I guess we don't need to be clearer about this only applying to gates in Mercurial (and that being the difference between 10 and NV)? > The following "paperwork items" in the bug (CR) should be done: > .... > * With respect to the Suggested Fix text, .... > - Each source module's full path (e.g., usr/src/.../foo.c) should be > specified in the Suggested Fix text. Further, this text field should > contain the diffs for each affected module. Context diffs (diff -c or > diff -u, or sccs diffs -C or hg pdiff) are preferred if they will fit. > ... > - ... disappear shortly after integration. [ was: "putback" ] > ... > - The diffs should be pointing the "right" way. webrev, sccs diffs > and hg pdiff will get this right; using diff from the command line, > make sure you do diff old new. > ... > > * For Nevada builds 97 and later, the RTI should have your `hg outgoing -v` > in the putback -n section and a pointer to your webrev in the comments > section. For Solaris 10 updates and older sustaining releases, the RTI > should also have your `putback -n` in the putback -n section and a > pointer to your webrev in the comments section. > > ... > > * Other more general nits: > - No bug IDs in the source code; the sccs delta comments and > the Mercurial changeset descriptions cover that. "or the" not "and the", I think. -- Rich
