* Re: A patch for toplevel Makefile.in [not found] ` <38CD8CF3.CA81E01@cygnus.com> @ 2000-12-30 6:08 ` Jonathan Larmour 2000-03-20 12:56 ` Jonathan Larmour 2000-12-30 6:08 ` Jim Kingdon 0 siblings, 2 replies; 18+ messages in thread From: Jonathan Larmour @ 2000-12-30 6:08 UTC (permalink / raw) To: Andrew Cagney; +Cc: overseers 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: A patch for toplevel Makefile.in 2000-12-30 6:08 ` A patch for toplevel Makefile.in Jonathan Larmour @ 2000-03-20 12:56 ` Jonathan Larmour 2000-12-30 6:08 ` Jim Kingdon 1 sibling, 0 replies; 18+ messages in thread From: Jonathan Larmour @ 2000-03-20 12:56 UTC (permalink / raw) To: Andrew Cagney; +Cc: overseers 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: A patch for toplevel Makefile.in 2000-12-30 6:08 ` A patch for toplevel Makefile.in Jonathan Larmour 2000-03-20 12:56 ` Jonathan Larmour @ 2000-12-30 6:08 ` Jim Kingdon 2000-03-20 13:11 ` Jim Kingdon ` (3 more replies) 1 sibling, 4 replies; 18+ messages in thread From: Jim Kingdon @ 2000-12-30 6:08 UTC (permalink / raw) To: jlarmour; +Cc: ac131313, overseers > 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: A patch for toplevel Makefile.in 2000-12-30 6:08 ` Jim Kingdon @ 2000-03-20 13:11 ` Jim Kingdon 2000-12-30 6:08 ` Frank Ch. Eigler ` (2 subsequent siblings) 3 siblings, 0 replies; 18+ messages in thread From: Jim Kingdon @ 2000-03-20 13:11 UTC (permalink / raw) To: jlarmour; +Cc: ac131313, overseers > 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: A patch for toplevel Makefile.in 2000-12-30 6:08 ` Jim Kingdon 2000-03-20 13:11 ` Jim Kingdon @ 2000-12-30 6:08 ` Frank Ch. Eigler 2000-03-20 14:35 ` Frank Ch. Eigler 2000-12-30 6:08 ` Andrew Cagney 2000-12-30 6:08 ` Ian Lance Taylor 3 siblings, 1 reply; 18+ messages in thread From: Frank Ch. Eigler @ 2000-12-30 6:08 UTC (permalink / raw) To: Jim Kingdon; +Cc: jlarmour, overseers 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----- ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: A patch for toplevel Makefile.in 2000-12-30 6:08 ` Frank Ch. Eigler @ 2000-03-20 14:35 ` Frank Ch. Eigler 0 siblings, 0 replies; 18+ messages in thread From: Frank Ch. Eigler @ 2000-03-20 14:35 UTC (permalink / raw) To: Jim Kingdon; +Cc: jlarmour, overseers 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----- ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: A patch for toplevel Makefile.in 2000-12-30 6:08 ` Jim Kingdon 2000-03-20 13:11 ` Jim Kingdon 2000-12-30 6:08 ` Frank Ch. Eigler @ 2000-12-30 6:08 ` Andrew Cagney 2000-03-20 15:31 ` Andrew Cagney 2000-12-30 6:08 ` Jason Molenda 2000-12-30 6:08 ` Ian Lance Taylor 3 siblings, 2 replies; 18+ messages in thread From: Andrew Cagney @ 2000-12-30 6:08 UTC (permalink / raw) To: jlarmour, Jim Kingdon; +Cc: ac131313, overseers 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: A patch for toplevel Makefile.in 2000-12-30 6:08 ` Andrew Cagney @ 2000-03-20 15:31 ` Andrew Cagney 2000-12-30 6:08 ` Jason Molenda 1 sibling, 0 replies; 18+ messages in thread From: Andrew Cagney @ 2000-03-20 15:31 UTC (permalink / raw) To: jlarmour, Jim Kingdon; +Cc: ac131313, overseers 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: A patch for toplevel Makefile.in 2000-12-30 6:08 ` Andrew Cagney 2000-03-20 15:31 ` Andrew Cagney @ 2000-12-30 6:08 ` Jason Molenda 2000-03-20 18:38 ` Jason Molenda ` (2 more replies) 1 sibling, 3 replies; 18+ messages in thread From: Jason Molenda @ 2000-12-30 6:08 UTC (permalink / raw) To: Andrew Cagney; +Cc: jlarmour, Jim Kingdon, ac131313, overseers 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! ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: A patch for toplevel Makefile.in 2000-12-30 6:08 ` Jason Molenda @ 2000-03-20 18:38 ` Jason Molenda 2000-12-30 6:08 ` Andrew Cagney 2000-12-30 6:08 ` Jason Molenda 2 siblings, 0 replies; 18+ messages in thread From: Jason Molenda @ 2000-03-20 18:38 UTC (permalink / raw) To: Andrew Cagney; +Cc: jlarmour, Jim Kingdon, ac131313, overseers 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! ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: A patch for toplevel Makefile.in 2000-12-30 6:08 ` Jason Molenda 2000-03-20 18:38 ` Jason Molenda @ 2000-12-30 6:08 ` Andrew Cagney 2000-03-20 20:15 ` Andrew Cagney 2000-12-30 6:08 ` Jason Molenda 2 siblings, 1 reply; 18+ messages in thread From: Andrew Cagney @ 2000-12-30 6:08 UTC (permalink / raw) To: Jason Molenda; +Cc: jlarmour, Jim Kingdon, overseers 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: A patch for toplevel Makefile.in 2000-12-30 6:08 ` Andrew Cagney @ 2000-03-20 20:15 ` Andrew Cagney 0 siblings, 0 replies; 18+ messages in thread From: Andrew Cagney @ 2000-03-20 20:15 UTC (permalink / raw) To: Jason Molenda; +Cc: jlarmour, Jim Kingdon, overseers 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: A patch for toplevel Makefile.in 2000-12-30 6:08 ` Jason Molenda 2000-03-20 18:38 ` Jason Molenda 2000-12-30 6:08 ` Andrew Cagney @ 2000-12-30 6:08 ` Jason Molenda 2000-03-20 18:43 ` Jason Molenda 2 siblings, 1 reply; 18+ messages in thread From: Jason Molenda @ 2000-12-30 6:08 UTC (permalink / raw) To: Andrew Cagney; +Cc: jlarmour, Jim Kingdon, ac131313, overseers 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: A patch for toplevel Makefile.in 2000-12-30 6:08 ` Jason Molenda @ 2000-03-20 18:43 ` Jason Molenda 0 siblings, 0 replies; 18+ messages in thread From: Jason Molenda @ 2000-03-20 18:43 UTC (permalink / raw) To: Andrew Cagney; +Cc: jlarmour, Jim Kingdon, ac131313, overseers 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: A patch for toplevel Makefile.in 2000-12-30 6:08 ` Jim Kingdon ` (2 preceding siblings ...) 2000-12-30 6:08 ` Andrew Cagney @ 2000-12-30 6:08 ` Ian Lance Taylor 2000-03-20 19:43 ` Ian Lance Taylor 2000-12-30 6:08 ` Jim Kingdon 3 siblings, 2 replies; 18+ messages in thread From: Ian Lance Taylor @ 2000-12-30 6:08 UTC (permalink / raw) To: kingdon; +Cc: jlarmour, ac131313, overseers 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: A patch for toplevel Makefile.in 2000-12-30 6:08 ` Ian Lance Taylor @ 2000-03-20 19:43 ` Ian Lance Taylor 2000-12-30 6:08 ` Jim Kingdon 1 sibling, 0 replies; 18+ messages in thread From: Ian Lance Taylor @ 2000-03-20 19:43 UTC (permalink / raw) To: kingdon; +Cc: jlarmour, ac131313, overseers 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: A patch for toplevel Makefile.in 2000-12-30 6:08 ` Ian Lance Taylor 2000-03-20 19:43 ` Ian Lance Taylor @ 2000-12-30 6:08 ` Jim Kingdon 2000-03-20 20:09 ` Jim Kingdon 1 sibling, 1 reply; 18+ messages in thread From: Jim Kingdon @ 2000-12-30 6:08 UTC (permalink / raw) To: ian; +Cc: jlarmour, ac131313, overseers 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: A patch for toplevel Makefile.in 2000-12-30 6:08 ` Jim Kingdon @ 2000-03-20 20:09 ` Jim Kingdon 0 siblings, 0 replies; 18+ messages in thread From: Jim Kingdon @ 2000-03-20 20:09 UTC (permalink / raw) To: ian; +Cc: jlarmour, ac131313, overseers 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2000-12-30 6:08 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20000310125542.A6624@valinux.com> [not found] ` <38CD8CF3.CA81E01@cygnus.com> 2000-12-30 6:08 ` A patch for toplevel Makefile.in Jonathan Larmour 2000-03-20 12:56 ` Jonathan Larmour 2000-12-30 6:08 ` Jim Kingdon 2000-03-20 13:11 ` Jim Kingdon 2000-12-30 6:08 ` Frank Ch. Eigler 2000-03-20 14:35 ` Frank Ch. Eigler 2000-12-30 6:08 ` Andrew Cagney 2000-03-20 15:31 ` Andrew Cagney 2000-12-30 6:08 ` Jason Molenda 2000-03-20 18:38 ` Jason Molenda 2000-12-30 6:08 ` Andrew Cagney 2000-03-20 20:15 ` Andrew Cagney 2000-12-30 6:08 ` Jason Molenda 2000-03-20 18:43 ` Jason Molenda 2000-12-30 6:08 ` Ian Lance Taylor 2000-03-20 19:43 ` Ian Lance Taylor 2000-12-30 6:08 ` Jim Kingdon 2000-03-20 20:09 ` Jim Kingdon
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).