Re: A patch for toplevel Makefile.in

[Jason Molenda <jason@molenda.com>]

Is it that important to strictly control the top-level files? We
never did it with the Cygnus repo; we expected people to commit
reasonable changes, and if they screwed something up, we expected
them to fix it.

At the top-level, we have

  libiberty & libiberty's part of include/ 
     IIRC we declared GCC to be the master home for these files.  So
     changes need to be done in tandem with the GCC project, or entered
     in to the GCC repo and migrated over via a merge.

  BFD's part of include/
     Goes through the binutils project

  config.guess, config.sub
     Master sources are at gnu.org; changes need to be done in tandem
     with these sources or submitted to the master file maintainer and
     brought in via a merge.

  configure configure.in Makefile.in (and config-ml.in, config.if, and other
  assorted never-changing files)
     IMHO the same method we had at Cygnus (check in tested changes, be
     prepared to respond to any problems that crop up due to your change)
     can go.

  modules file
     Obviously changes to this file should not go through Jim
     Kingdon, or any central place.  If you understand the file
     format (or can cut-and-paste existing entries), modify it.
     If it scares you, get someone who does understand it to help 
     you.  Be prepared to fix it if you do break it.


Is something more formal necessary?  Is a -patches list necessary?
I mean, say a problem comes up in the top-level configure.in, and
someone who is using gdb has the problem.  They send a patch to
gdb-patches.  The gdb maintainers think it looks reasonable, why
not check it in?  Or if a binutils maintainer finds a problem with
the Makefile.in, and nickc thinks it is a reasonable change, it
seems OK to me for him to check it in.

If a person, oh say like me, sees the mpw-* files sitting there,
having not been touched for four or five years, having no chance
of working with current day sources, why shouldn't I just remove
them?  Oh, I know Stan thinks they should stay around until the
end of time :-), but is it really that big of a deal if I remove
them?  Do I need to go through a formal approval process for
something like this?


In fact, I think the mpw thing is probably the most contentious
thing I could come up with -- I think they should go away, and
another person (another person with _write_ _access_ :-) thinks
they should stay.  I would say that we need to reach some kind of
mutual understanding before proceeding.  (my version of mutual
understanding:  I have root, Stan doesn't.  I win.  :-)

If anyone were to be annoyed about people touching the top-level
files willy-nilly, it would be Chris Faylor.  The most likely target
to break from any given change is, of course, cygwin, and he'll
have to chase after random patches that break canadian cross
building.


Well, my two cents.  Down with bureaucracy. 

Jason
Free the Software!