Re: A patch for toplevel Makefile.in

Re: A patch for toplevel Makefile.in

[Jonathan Larmour]

Andrew Cagney wrote:
> 
[snip]
> > and their followups. I suggest gcc should also consider this patch.
> 
> (To flog a dead horse...)
> Please cross post this sort of change to
> gdb-patches@sourceware.cygnus.com

Perhaps we should consider adding a src-patches@sourceware list?

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

Re: A patch for toplevel Makefile.in

[Jonathan Larmour]

Andrew Cagney wrote:
> 
[snip]
> > and their followups. I suggest gcc should also consider this patch.
> 
> (To flog a dead horse...)
> Please cross post this sort of change to
> gdb-patches@sourceware.cygnus.com

Perhaps we should consider adding a src-patches@sourceware list?

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

Re: A patch for toplevel Makefile.in

[Jim Kingdon]

> Perhaps we should consider adding a src-patches@sourceware list?

Speaking of which, can the relevant people (gdb maintainer(s),
binutils maintainer, newlib maintainer, whoever) get together and pick
a project leader(s) for the "src" project?

Right now people are sending me things like changes to the modules
file, and that really should be a project issue rather than a
sourceware issue.

P.S. src-patches@sourceware sounds good to me.  But I'm not sure who
is supposed to decide these things the way things are now.

Re: A patch for toplevel Makefile.in

[Jim Kingdon]

> Perhaps we should consider adding a src-patches@sourceware list?

Speaking of which, can the relevant people (gdb maintainer(s),
binutils maintainer, newlib maintainer, whoever) get together and pick
a project leader(s) for the "src" project?

Right now people are sending me things like changes to the modules
file, and that really should be a project issue rather than a
sourceware issue.

P.S. src-patches@sourceware sounds good to me.  But I'm not sure who
is supposed to decide these things the way things are now.

Re: A patch for toplevel Makefile.in

[Ian Lance Taylor]

   Date: Mon, 20 Mar 2000 16:11:02 -0500
   From: Jim Kingdon <kingdon@redhat.com>

   > Perhaps we should consider adding a src-patches@sourceware list?

   Speaking of which, can the relevant people (gdb maintainer(s),
   binutils maintainer, newlib maintainer, whoever) get together and pick
   a project leader(s) for the "src" project?

   Right now people are sending me things like changes to the modules
   file, and that really should be a project issue rather than a
   sourceware issue.

   P.S. src-patches@sourceware sounds good to me.  But I'm not sure who
   is supposed to decide these things the way things are now.

So far we've gotten by with a general state of good-natured anarchy,
and as far as I am concerned that can continue.  In any case, I
reserve the right to complain about top-level changes that affect the
binutils.

As far as the modules file goes, I think people should just check in
changes provided they don't break anything.

Ian

Re: A patch for toplevel Makefile.in

[Ian Lance Taylor]

   Date: Mon, 20 Mar 2000 16:11:02 -0500
   From: Jim Kingdon <kingdon@redhat.com>

   > Perhaps we should consider adding a src-patches@sourceware list?

   Speaking of which, can the relevant people (gdb maintainer(s),
   binutils maintainer, newlib maintainer, whoever) get together and pick
   a project leader(s) for the "src" project?

   Right now people are sending me things like changes to the modules
   file, and that really should be a project issue rather than a
   sourceware issue.

   P.S. src-patches@sourceware sounds good to me.  But I'm not sure who
   is supposed to decide these things the way things are now.

So far we've gotten by with a general state of good-natured anarchy,
and as far as I am concerned that can continue.  In any case, I
reserve the right to complain about top-level changes that affect the
binutils.

As far as the modules file goes, I think people should just check in
changes provided they don't break anything.

Ian

Re: A patch for toplevel Makefile.in

[Jim Kingdon]

OK, OK, I get the picture.

Anarchy will prevail for now and I'll operate under the assumption
that the Responsible Parties (There Are No Responsible Parties) will
be the ones to take the lead on any changes, rather than Sourceware
Central(TM).

I have informed the one person who had emailed me a patch to the
modules file and will plan to answer future enquiries likewise.

Re: A patch for toplevel Makefile.in

[Jim Kingdon]

OK, OK, I get the picture.

Anarchy will prevail for now and I'll operate under the assumption
that the Responsible Parties (There Are No Responsible Parties) will
be the ones to take the lead on any changes, rather than Sourceware
Central(TM).

I have informed the one person who had emailed me a patch to the
modules file and will plan to answer future enquiries likewise.

Re: A patch for toplevel Makefile.in

[Frank Ch. Eigler]

Hi -

On Mon, Mar 20, 2000 at 04:11:02PM -0500, Jim Kingdon wrote:
> Speaking of which, can the relevant people (gdb maintainer(s),
> binutils maintainer, newlib maintainer, whoever) get together and pick
> a project leader(s) for the "src" project?

How about "srcmasters" mailing list with a union of subtree maintainers?

> [...] But I'm not sure who
> is supposed to decide these things the way things are now.

Would someone object if you "just do it"?

- FChE
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE41qe5VZbdDOm/ZT0RAZI9AJ0WfudQ2Esb5MJn3cSdECXU+Qj9PACdElrs
OVIKETMGL3M9AEqM0lD603Q=
=i+uW
-----END PGP SIGNATURE-----

Re: A patch for toplevel Makefile.in

[Frank Ch. Eigler]

Hi -

On Mon, Mar 20, 2000 at 04:11:02PM -0500, Jim Kingdon wrote:
> Speaking of which, can the relevant people (gdb maintainer(s),
> binutils maintainer, newlib maintainer, whoever) get together and pick
> a project leader(s) for the "src" project?

How about "srcmasters" mailing list with a union of subtree maintainers?

> [...] But I'm not sure who
> is supposed to decide these things the way things are now.

Would someone object if you "just do it"?

- FChE
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE41qe5VZbdDOm/ZT0RAZI9AJ0WfudQ2Esb5MJn3cSdECXU+Qj9PACdElrs
OVIKETMGL3M9AEqM0lD603Q=
=i+uW
-----END PGP SIGNATURE-----

Re: A patch for toplevel Makefile.in

[Andrew Cagney]

Excerpts from mail: 20-Mar-100 Re: A patch for toplevel Ma.. Jim
Kingdon@redhat.com (524*)

> > Perhaps we should consider adding a src-patches@sourceware list?

> Speaking of which, can the relevant people (gdb maintainer(s),
> binutils maintainer, newlib maintainer, whoever) get together and pick
> a project leader(s) for the "src" project?

At present binutils' (1) Ian L.T. is the defacto maintainer for any
stuff in the src directory.  I pleed for a cross post so that gdb people
at least know something has/is about to change.  The GDB people are very
unlikely to try to veto any changes.

For what its worth I tabled a suggestion (to binutils) to add a
src/MAINTAINERS file that would explain top level maintainership issues.

> Right now people are sending me things like changes to the modules
> file, and that really should be a project issue rather than a
> sourceware issue.

> P.S. src-patches@sourceware sounds good to me.  But I'm not sure who
> is supposed to decide these things the way things are now.

Could work.  Would still need a standard place for people to look to
determine what the rules are.

enjoy,
	Andrew

(1) Wonder if that quote is correct

Re: A patch for toplevel Makefile.in

[Andrew Cagney]

Excerpts from mail: 20-Mar-100 Re: A patch for toplevel Ma.. Jim
Kingdon@redhat.com (524*)

> > Perhaps we should consider adding a src-patches@sourceware list?

> Speaking of which, can the relevant people (gdb maintainer(s),
> binutils maintainer, newlib maintainer, whoever) get together and pick
> a project leader(s) for the "src" project?

At present binutils' (1) Ian L.T. is the defacto maintainer for any
stuff in the src directory.  I pleed for a cross post so that gdb people
at least know something has/is about to change.  The GDB people are very
unlikely to try to veto any changes.

For what its worth I tabled a suggestion (to binutils) to add a
src/MAINTAINERS file that would explain top level maintainership issues.

> Right now people are sending me things like changes to the modules
> file, and that really should be a project issue rather than a
> sourceware issue.

> P.S. src-patches@sourceware sounds good to me.  But I'm not sure who
> is supposed to decide these things the way things are now.

Could work.  Would still need a standard place for people to look to
determine what the rules are.

enjoy,
	Andrew

(1) Wonder if that quote is correct

Re: A patch for toplevel Makefile.in

[Jason Molenda]

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!

Re: A patch for toplevel Makefile.in

[Jason Molenda]

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!

Re: A patch for toplevel Makefile.in

[Andrew Cagney]

Jason Molenda wrote:
> 
> 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.

I just want to know if something changed.  If someone commits a src/gdb
change they post a patch to gdb-patches.  If someone commits a src/bfd
change they post a patch to binutils.  If someone changes an interface
(ex src/include) (and possibly breaks a GDB build :-) the patch is cross
posted to where it is relevant.

This is a plea for that basic level of communication to occure at the
top level.

> 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

except the bits that define gdb<->sim interfaces which go through
gdb-patches :-)

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

FYI,

Something like that (plus a list of all the relevant mailing lists) was
all I intended putting in the proposed ``src/MAINTAINERS'' file. ``What
do I do with this patch?'' ``Check the MAINTAINERS file.''

Mind if I cut/paste it?

	Andrew

Re: A patch for toplevel Makefile.in

[Andrew Cagney]

Jason Molenda wrote:
> 
> 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.

I just want to know if something changed.  If someone commits a src/gdb
change they post a patch to gdb-patches.  If someone commits a src/bfd
change they post a patch to binutils.  If someone changes an interface
(ex src/include) (and possibly breaks a GDB build :-) the patch is cross
posted to where it is relevant.

This is a plea for that basic level of communication to occure at the
top level.

> 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

except the bits that define gdb<->sim interfaces which go through
gdb-patches :-)

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

FYI,

Something like that (plus a list of all the relevant mailing lists) was
all I intended putting in the proposed ``src/MAINTAINERS'' file. ``What
do I do with this patch?'' ``Check the MAINTAINERS file.''

Mind if I cut/paste it?

	Andrew

Re: A patch for toplevel Makefile.in

[Jason Molenda]

Two notes,

On Mon, Mar 20, 2000 at 06:30:25PM -0800, Jason Molenda wrote:

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

Obviously someone in the binutils group should not be farting around
with the gdb module, for instance.  I'm talking about new modules
being added or someone modifying their own project's module config.




> 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?  


Allow me to provide my own counter argument. :-)  I cited one case
where two people with write access disagree; here is a better one.
Say a volunteer wants to rewrite the top-level files to be
autoconf/automake based.  Rah rah, we're all for that.  Who should
he work with?  Who should he talk to about special cases, about
canadian crosses?  This -- the most drastic example I can think of --
is a case where some kind of central figurehead could be of use.


J

Re: A patch for toplevel Makefile.in

[Jason Molenda]

Two notes,

On Mon, Mar 20, 2000 at 06:30:25PM -0800, Jason Molenda wrote:

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

Obviously someone in the binutils group should not be farting around
with the gdb module, for instance.  I'm talking about new modules
being added or someone modifying their own project's module config.




> 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?  


Allow me to provide my own counter argument. :-)  I cited one case
where two people with write access disagree; here is a better one.
Say a volunteer wants to rewrite the top-level files to be
autoconf/automake based.  Rah rah, we're all for that.  Who should
he work with?  Who should he talk to about special cases, about
canadian crosses?  This -- the most drastic example I can think of --
is a case where some kind of central figurehead could be of use.


J