PROPOSAL: Variation on an Alternate policy for obsoleting targets

PROPOSAL: Variation on an Alternate policy for obsoleting targets

[Bruce Korb]

In the interests of keeping fixinc from becoming a monotonically increasing
behemoth, I propose the following 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.

Maintainers would make at least one build with a GCC_MAINTAINER_MODE
environment variable set.  fixinc would detect that in the build and
record the machine triplet/quadruplet and the set of fix tests and
fixes that got applied during the build.  That information would get
pasted into the test results and mailed in.  This would provide a
means for determining some of the fixes that are not being used anymore.
This would also ensure that maintainers were at least monitoring GCC's
progress.  :)

 - Bruce

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

[Paul Koning]

>>>>> "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".

   paul

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

[Bruce Korb]

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.

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

[DJ Delorie]

> Maintainers would make at least one build with a GCC_MAINTAINER_MODE
> environment variable set.

Not all native targets support maintainer mode.  Not all native
targets even support testing.

IMHO any requirement for active participation to keep from being
obsoleted is not the right solution.

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

[Bruce Korb]

DJ Delorie wrote:
> 
> > Maintainers would make at least one build with a GCC_MAINTAINER_MODE
> > environment variable set.
> 
> Not all native targets support maintainer mode.  Not all native
> targets even support testing.
> 
> IMHO any requirement for active participation to keep from being
> obsoleted is not the right solution.

OK.  That means the fixes will grow without bound.  The only hint
about applicable platforms is in the comments and fix names.  But
hints are only hints and not gospel.  Somehow, any supported platform
needs to have the supporter communicating with GCC development in
some way, yes?  Otherwise, what does it mean to say the platform
is supported?  All I'm asking for is:

  WHATEVERYOUWANTTOCALLIT=true
  export WHATEVERYOUWANTTOCALLIT

  <<do all the building and optional testing during which fixincl
    will do its thing>>

  /bin/mail -s "fixinc results for `config.guess`" gcc-fixinc@gcc.gnu.org \
      < somefile

If this is too much for some maintainer, couldn't it be argued
that this maintainer is not maintaining?

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

[DJ Delorie]

> Somehow, any supported platform needs to have the supporter
> communicating with GCC development in some way, yes?

No.  If the platform happens to work, there's no need for a maintainer
to communicate with us.

> Otherwise, what does it mean to say the platform is supported?

Lack of support does not imply need for deprecation.  A platform can
"happen to work" with no effort on the part of the gcc developers.

And as we've already seen, some platforms are supported by groups
outside of gcc development, who are in general happy with a target
that doesn't happen to be useful as-is out of the gcc source tree, but
would still be inconvenienced if that target were deprecated.

> If this is too much for some maintainer, couldn't it be argued that
> this maintainer is not maintaining?

I don't agree that cleaning up unused code is part of a target
maintainer's job.  A target maintainer's job is to ensure that the
target continues to work, regardless of how much or how little effort
that requires.

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

[Joe Buck]

On Mon, May 19, 2003 at 02:28:36PM -0400, DJ Delorie wrote:
> Not all native targets support maintainer mode.  Not all native
> targets even support testing.

For example, I recently built 3.3 on a very old Alpha OSF/1 box.
As the "expect" program fails to build on that system, I can't submit
tests, but the compiler appears to work.

(I'm sure that the problem with "expect" is fixable, but it's not worth
the bother for me personally; I just noticed that our porting center had
this box around and tried it to see if it would work). 

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

[Bruce Korb]

Joe Buck wrote:
> 
> On Mon, May 19, 2003 at 02:28:36PM -0400, DJ Delorie wrote:
> > Not all native targets support maintainer mode.  Not all native
> > targets even support testing.
> 
> For example, I recently built 3.3 on a very old Alpha OSF/1 box.
> As the "expect" program fails to build on that system, I can't submit
> tests, but the compiler appears to work.
> 
> (I'm sure that the problem with "expect" is fixable, but it's not worth
> the bother for me personally; I just noticed that our porting center had
> this box around and tried it to see if it would work).

Would it be too much trouble to set an environment variable
and email in the resulting report file?  (Were it implemented.)
No expect required.

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

[Joe Buck]

I wrote:
> > On Mon, May 19, 2003 at 02:28:36PM -0400, DJ Delorie wrote:
> > > Not all native targets support maintainer mode.  Not all native
> > > targets even support testing.
> > 
> > For example, I recently built 3.3 on a very old Alpha OSF/1 box.
> > As the "expect" program fails to build on that system, I can't submit
> > tests, but the compiler appears to work.
> > 
> > (I'm sure that the problem with "expect" is fixable, but it's not worth
> > the bother for me personally; I just noticed that our porting center had
> > this box around and tried it to see if it would work).
 
On Mon, May 19, 2003 at 09:30:40PM -0700, Bruce Korb wrote:
> Would it be too much trouble to set an environment variable
> and email in the resulting report file?  (Were it implemented.)
> No expect required.

I don't understand what you have in mind.  Could you explain?

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

[Bruce Korb]

Joern Rennecke wrote:
> 
> Bruce Korb wrote:
> > Would it be too much trouble to set an environment variable
> > and email in the resulting report file?  (Were it implemented.)

> [Would] the report be large?

It would contain one line for every fix that got triggered,
whether for one header or many headers.  Most platforms would
have under a dozen lines, plus some introductory overhead and
the config.guess output.  I could jigger it to include other
stuff for bug reporting, if that were considered useful.

>  If not, it might be useful to have
> it produced by default, for debugging purposes when something
> goes awry.
> And we could change the instructions how to report a
> successful build so that people just have to grab this file
> and mail it to a specified address.  Considering how hard it
> is for some people to report the output of config.guess (we've
> gotten some copies of config.guess instead) it might be safer to
> quote a filename of a file that is only generated by a build.

A build info file, of sorts.  Sure.  Define such a file and let
any part of the build add useful information, as long as the
size were kept "reasonable" and you figured out how to handle
parallel builds.

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

[Joern Rennecke]

Bruce Korb wrote:
> Would it be too much trouble to set an environment variable
> and email in the resulting report file?  (Were it implemented.)
> No expect required.

Will the report be large?  If not, it might be useful to have
it produced by default, for debugging purposes when something
goes awry.
And we could change the instructions how to report a
successful build so that people just have to grab this file
and mail it to a specified address.  Considering how hard it
is for some people to report the output of config.guess (we've
gotten some copies of config.guess instead) it might be safer to
quote a filename of a file that is only generated by a build.

-- 
--------------------------
SuperH (UK) Ltd.
2410 Aztec West / Almondsbury / BRISTOL / BS32 4QX
T:+44 1454 465658