Mark J. Nelson writes:
> James Carlson wrote:
> > Ali Bahrami writes:
> >> Of course this is not perfectly seamless --- the person integrating
> >> process_mapfile will still be confronted with some confusing errors,
> >> and will have to augment the exception file to make them go away.
> >
> > Right; there'll need to be some sort of guidance to other gatelings
> > about fixing such problems either way. But how many of these
> > "special" files exist? If we're talking about four or five files that
> > have crept into the 30K+ ON file list over the last 20+ years, then
> > maybe it's not something to worry too much about.
>
> Meaning "just go ahead and change em," or "leave 'em as they are"?
The former -- "just go ahead and change 'em." If there are just a
few, then it shouldn't be an on-going concern.
> I suggested that Ali add, in addition, the file
>
> ${REPO}/exception_lists/${tool}
That makes sense to me.
> which, if existent, would specify on a tracked, per-repository basis
> files that were known to not be compliant with particular checks.
>
> On further thought, it seems like there's overlap, right? *.NOT entries
> SHOULD, on integration, be migrated into exception_list/* files.
>
> ?
There are a *few* cases where those entries should not be migrated.
The one that comes to mind immediately is copyright.NOT: if I'm making
some trivial changes that would ordinarily require me to leave the
copyright year untouched, I would likely put those files into my
private copyright.NOT file, and pushing the change out to the gate as
a general exception would be _wrong_ for all future users.
In most cases, though, I agree with you, and would go further: rather
than using *.NOT at all, if we had exception_list/*, most casual uses
of list entries _should_ go to the latter, and reviewers should ask
for clear justification why any workspace has *.NOT files.
> > Actually, what I was saying was that renaming the files (even old
> > ones) shouldn't be rejected just out of hand, because testing to make
> > sure that the change itself was complete and correct would be fairly
> > trivial, and wouldn't involve re-running any special test suites.
> >
> > Adding a version number change check to '-w' is an added dimension.
> > It sounds like a worthwhile thing to me, and something that wouldn't
> > suffer from any of the file name problems that checking map files
> > would. I agree that it's separate.
>
> You're now talking about checking the shared objects, instead of the
> mapfiles. Seems reasonable, but I still would like mapfile changes to
> be more directly tested, even when wsdiff is not invoked.
I was commenting on Ali's seeming misunderstanding of my original
comment; he brought up adding -w enhancements, when I was merely
saying that renaming files (if that's how the changes are wrought)
shouldn't be a serious concern.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
