Re: PROPOSAL: Variation on an Alternate policy for obsoleting targets

[Bruce Korb <bkorb at veritas dot com>]

Paul Koning wrote:
> 
> >>>>> "Bruce" == Bruce Korb <bkorb@veritas.com> writes:
> 
>  Bruce> In the interests of keeping fixinc from becoming a
>  Bruce> monotonically increasing behemoth, I propose the following
>  Bruce> addition:
> 
>  >> Now for the actual obsolescence rule. :-)
>  >>
>  >> Any target which has significant custom code (for instance, its
>  >> own subdirectory or file under config/) requires a maintainer.
>  >> This is most of them.
>  >>
>  >> Any such target without a maintainer is advertised as needing one.
> 
>  Bruce> Maintainers would make at least one build with a
>  Bruce> GCC_MAINTAINER_MODE environment variable set.
> 
> Is there any documentation that explains what that does?  I've only
> seen statements that amount to "this does magical things that only
> maintainer need".

Well, if anyone is using it for anything, I don't know about it.  :)
It was a proposal to use it for hacking on fixincludes.  I would modify
the program to remember which fixes were triggered and when it was done
it would produce a usage report suitable for automated mail handling.
With that email, we'd know the target triplet for which GCC had been
built and a subset of fixinc fixes that still need to be kept alive.
At the end of a development cycle, any fixes not marked as still in use
would be marked deprecated.  Deprecated fixes would trigger an extra
special message under GCC_MAINTAINER_MODE, like:

   WARNING:  mumble is a zombie fixinc fix

and add it to the email.  Deprecated fixes that didn't trigger a
zombie message would be deleted next time around.