We have no active maintainer for the i386 port
Hi, We currently do not have an active maintainer for the i386 port. The only listed maintainer for the port is rth, and he hasn't been around to approve patches in a while. This situation is a bit strange for a port that IMHO is one of the most important ports GCC has... In the mean time, patches don't get approved (see e.g. [1]), or they get approved by middle-end maintainers who, strictly speaking, should not be approving backend patches, as I understand it. So, can the SC please appoint a new/extra i386 port maintainer? Thanks, Gr. Steven [1] http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00379.html
Re: We have no active maintainer for the i386 port
On Sat, Jan 06, 2007 at 04:42:27PM +0100, Steven Bosscher wrote: > Hi, > > We currently do not have an active maintainer for the i386 port. The > only listed maintainer for the port is rth, and he hasn't been around > to approve patches in a while. This situation is a bit strange for > a port that IMHO is one of the most important ports GCC has... > > In the mean time, patches don't get approved (see e.g. [1]), or they > get approved by middle-end maintainers who, strictly speaking, should > not be approving backend patches, as I understand it. > > So, can the SC please appoint a new/extra i386 port maintainer? > I think it is overdue. H.J.
Re: We have no active maintainer for the i386 port
On Sat, 6 Jan 2007, Steven Bosscher wrote: > Hi, > > We currently do not have an active maintainer for the i386 port. The > only listed maintainer for the port is rth, and he hasn't been around > to approve patches in a while. This situation is a bit strange for > a port that IMHO is one of the most important ports GCC has... > > In the mean time, patches don't get approved (see e.g. [1]), or they > get approved by middle-end maintainers who, strictly speaking, should > not be approving backend patches, as I understand it. Just to clarify, middle-end maintainers *do* have the ability to approve patches in the config/ directory for any target. We expect them to use their own judgement as to whether they are qualified for a particular backend. It's the same trust we place in global write maintainers who may not be familiar with every single backend out there but nevertheless are "allowed" to approve any patch in the tree. Here's the original announcement creating the position: http://gcc.gnu.org/ml/gcc/2003-10/msg00455.html > > So, can the SC please appoint a new/extra i386 port maintainer? I completely agree we need one or more new x86 maintainers. We are already discussing the issue, hopefully you'll see something posted soon. Thanks, --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: Do we want non-bootstrapping "make" back?
Richard Kenner wrote: Not much. I'm convinced it would be feasible, but definitely not easy, so I wanted to see how much interest there was - seems like some, but not a lot. Would this comprise retrofitting the support into the 4.2 branch? I don't think it's needed in the 4.2 branch since you can get the functionality with --disable-bootstrap (or whatever it's called). It's only in 4.3 that that option will be removed and hence the functionality otherwise lost. No, --disable-bootstrap *will* remain forever. What will be lost is the possibility to do ../configure --disable-bootstrap make bootstrap Paolo
Clarify policy on documentation changes [wwwdocs]
I just committed the patch below which clarifies that maintainers are allowed to make/approve changes to those parts of our documentation that are related to their area of maintainership. This is not a change in policy, just a clarification, but since there has been some uncertainty in this area I am also posting this to the gcc list, not just gcc-patches. Gerald PS: The change from "files" to "areas" in the second hunk is necessary because one file with documentation usually covers several, if not many areas of the compiler (think gcc/doc/invoke.texi, for example). Index: svnwrite.html === RCS file: /cvs/gcc/wwwdocs/htdocs/svnwrite.html,v retrieving revision 1.13 retrieving revision 1.14 diff -u -3 -p -r1.13 -r1.14 --- svnwrite.html 21 Sep 2006 14:17:36 - 1.13 +++ svnwrite.html 7 Jan 2007 00:12:34 - 1.14 @@ -105,9 +105,10 @@ developer to follow the appropriate poli Localized write permission. This is for people who have primary responsibility for ports, front ends, or significant hunks of code in the compiler. These - folks are allowed to make changes in code they maintain without + folks are allowed to make changes in code they maintain and + documentation related to that code without approval from anyone else, and approve other people's changes in - those files. They must get approval from the appropriate maintainers + those areas. They must get approval from the appropriate maintainers for changes elsewhere in the compiler. Maintainers of a port maintain the files in config/port/,
Re: proposal to clean up @node Warning Options in invoke.texi
Gerald Pfeifer wrote: Chris, I see you have not received any response to this yet, so let me give it a try. Thanks! I unsubscribed from the list and was surprised to see this in my inbox. Please continue to CC me on replies. On Sat, 28 Oct 2006, Chris Pickett wrote: 5. Fix what I have labelled as errors. That we definitely should do. I believe some things have been changed in our current development tree (to become GCC 4.3) already. It would be great could you have a look and perhaps produce a patch for one or more of these; is this something you could consider? Yes, I'll look at the trunk version, and send a series of patches. In case something ends up being longer than 10 lines, I haven't signed a copyright assignment form. I can do so, or I can waive all claim of copyright over anything I send, if that's acceptable. Cheers, Chris
