From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Molenda To: Andrew Cagney Cc: jlarmour@redhat.com, Jim Kingdon , ac131313@cygnus.com, overseers@sourceware.cygnus.com Subject: Re: A patch for toplevel Makefile.in Date: Sat, 30 Dec 2000 06:08:00 -0000 Message-id: <20000320183025.A5832@shell17.ba.best.com> References: <20000310125542.A6624@valinux.com> <38CD8CF3.CA81E01@cygnus.com> <38D69095.D3E30D4C@redhat.co.uk> <200003202111.QAA08994@devserv.devel.redhat.com> X-SW-Source: 2000/msg00228.html 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! From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Molenda To: Andrew Cagney Cc: jlarmour@redhat.com, Jim Kingdon , ac131313@cygnus.com, overseers@sourceware.cygnus.com Subject: Re: A patch for toplevel Makefile.in Date: Mon, 20 Mar 2000 18:38:00 -0000 Message-ID: <20000320183025.A5832@shell17.ba.best.com> References: <20000310125542.A6624@valinux.com> <38CD8CF3.CA81E01@cygnus.com> <38D69095.D3E30D4C@redhat.co.uk> <200003202111.QAA08994@devserv.devel.redhat.com> X-SW-Source: 2000-q1/msg00055.html Message-ID: <20000320183800.4mcoTIvSgzL4u2z5ns8JdujsghIKelyJFc9_K5Vbcm0@z> 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!