On Tue, 29 Jul 2008, Mark J. Nelson wrote:
>
>>> 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.
>
> Ditto on both. Don't know of any workspace checking scripts. If I recall
> correctly, the benefits generally fall into two categories: (ab)use of sccs,
> and "insufficient knowledge of packaging details." The former goes away, and
> the latter is still valid.
Some of the scripts used to also verify CRs against bugtraq+,
but that all broke when we migrated to bt2 :)
They tend to check for merge turds, multiple deltas, ident string
issues (all those go away, right?), copyright correctness,
files in conflict or uncommitted, and packaging correctness.
>>> 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.
>
> Yes. One RTI. Two "hg push" commands. The output of two "hg outgoing -v"
> commands in the RTI.
Okay, so I should probably add a general high level note like:
* Mixed (closed and open) source integrations
- You should have one RTI with all of the relevant output, as outlined
below and in webRTI, for both gates.
>
>>> 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.
>
> Should probably mention that, if you changed code in both open and closed
> repos, you'll need the output of "hg outgoing -v" for both. Similarly for
> webrev pointers.
Do you think the above high level note is sufficient?
Thank you,
Valerie
--
Valerie Fenwick, http://blogs.sun.com/bubbva
Solaris Security Technologies, Developer, Sun Microsystems, Inc.
17 Network Circle, Menlo Park, CA, 94025.
