From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10457 invoked by alias); 8 Oct 2003 13:43:50 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 10449 invoked from network); 8 Oct 2003 13:43:48 -0000 Received: from unknown (HELO redhat.com) (24.131.133.249) by sources.redhat.com with SMTP; 8 Oct 2003 13:43:48 -0000 Received: by redhat.com (Postfix, from userid 201) id DAE0732A8A7; Wed, 8 Oct 2003 09:43:47 -0400 (EDT) Date: Wed, 08 Oct 2003 13:43:00 -0000 From: Christopher Faylor To: Eli Zaretskii Cc: gdb@sources.redhat.com Subject: Re: Path handling bug in GDB included with MingW 3.1.0-1 Message-ID: <20031008134347.GA22562@redhat.com> Mail-Followup-To: Eli Zaretskii , gdb@sources.redhat.com References: <002d01c38b8a$6e2d34f0$2101a8c0@kyromaster> <1438-Tue07Oct2003231328+0200-eliz@elta.co.il> <20031007232234.GA13268@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-SW-Source: 2003-10/txt/msg00133.txt.bz2 On Wed, Oct 08, 2003 at 07:52:21AM +0200, Eli Zaretskii wrote: >> Date: Tue, 7 Oct 2003 19:22:34 -0400 >> From: Christopher Faylor >> >>Do we *really* want to go down the road of supporting a patched gdb >>here? There are people who are familiar with the changes that have >>gone into mingw gdb in the mingw mailing list. For whatever reason, >>they have chosen not to spend any time getting their patches back into >>gdb proper and do not, apparently, read this mailing list. >> >>I don't see any reason why we should be taking up bandwidth trying to >>support what is essentially a gdb fork here. > >Perhaps there's history to this that I'm not aware of. All I saw was a >question from a user of a GDB port for which I thought I could provide >some help at a price of a few moments required to write a short email >message. I don't see the alleged waste of bandwidth as a real issue >here (I doubt that you do, too), and have no idea how heavily is the >MinGW port patched and whether the patch authors unwillingness to send >the patches upstream is something that warrants a boycott on their >users. So it's your assertion that we should support anything with the name "gdb" in it no matter where it came from? I thought this mailing list was for supporting the FSF version of gdb. Should I have Red Hat gdb customers send their queries here, too? Or are we just drawing the line at commercial customers? >For the record, I do see it as a Good Thing to have the MinGW port as >part of the official GDB distro, and if my response was even a small >contribution to that, my time and our bandwidth were well spent. You >don't win the hearts of people by refusing to answer their questions, >at least in my experience. This is unrelated to whether it is a good thing to have MinGW as part of the gdb family. Again, this is a *gdb fork* we're talking about. The best you can do, since you don't have the actual source code, is offer opinions on what might be happening. That might be helpful but it also might lead someone astray. You could download the mingw patches, of course. Then you would be potentially tainted from doing further gdb development but you might be able to answer questions more definitively. Since there are people out there who are actually familiar with the source code in question, it makes sense to redirect queries to them. This is what I did. I did it in my capacity as the person responsible for gdb on Windows. >[Sorry for being a bit blunt, but I was quite astonished of being >pounced upon for answering a simple request.] Imagine my astonishment when as the Windows maintainer I tried to redirect the questions to the place where they would actually be answered only to see someone trying to answer the question anyway. I have been trying on and off for some time to get the MinGW authors to submit their code to the FSF, mentioning that gdb for mingw won't be supported until that happens. If we're going to support it anyway, then that rather dilutes my argument. cgf