From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30948 invoked by alias); 30 Sep 2004 13:26:34 -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 30917 invoked from network); 30 Sep 2004 13:26:32 -0000 Received: from unknown (HELO legolas.inter.net.il) (192.114.186.24) by sourceware.org with SMTP; 30 Sep 2004 13:26:32 -0000 Received: from zaretski ([80.230.152.240]) by legolas.inter.net.il (MOS 3.5.3-GR) with ESMTP id CSL11444 (AUTH halo1); Thu, 30 Sep 2004 15:26:03 +0200 (IST) Date: Thu, 30 Sep 2004 13:26:00 -0000 From: "Eli Zaretskii" To: Bob Rossi Message-ID: <01c4a6f0$Blat.v2.2.2$cc707360@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 CC: jingham@apple.com, gdb@sources.redhat.com, cagney@redhat.com, ezannoni@redhat.com, fnasser@redhat.com In-reply-to: <20040929025959.GA357@white> (message from Bob Rossi on Tue, 28 Sep 2004 22:59:59 -0400) Subject: Re: MI rules Reply-to: Eli Zaretskii References: <1095954341.19418.ezmlm@sources.redhat.com> <20040925010519.GB3379@white> <4E6C7AD8-0F25-11D9-AD7A-000D932CB92C@apple.com> <20040925201242.GA4133@white> <1AB1A5F6-10AC-11D9-8F3A-000A958F4C44@apple.com> <20040929025959.GA357@white> X-SW-Source: 2004-09/txt/msg00266.txt.bz2 > Date: Tue, 28 Sep 2004 22:59:59 -0400 > From: Bob Rossi > Cc: gdb@sources.redhat.com, cagney@redhat.com, ezannoni@redhat.com, > fnasser@redhat.com > > I have one quick note. I would prefer to get some cooperation with the > MI maintainers. I seriously need this cooperation in order to get > anything done with CGDB. Also, I consider the work I am doing necessary > for any front end developer to be able to write a reasonable front end > without having to heavily patch a version of GDB they distribute with. > > If you consider my goal worthy, please at least respond with some > reasonable criticism so that these issues can be resolved. I feel that in > many ways my views on the MI are mostly ignored by the MI maintainers. Out of those who are marked in MAINTAINERS as "MI maintainers" you can probably hope to get response only from Andrew, and Andrew has lots of other responsibilities and things to do. So I'm not surprised you feel the way you do. However, the issues you worry about need not wait for the ``MI maintainers'' to respond, quite a few (if not most) of them are general enough to be discussed with all the global maintainers, some of whom are more responsive. So I'd suggest to restructure the discussion so that more people could give you feedback. Speaking for myself, one of the more significants reasons that all but prevent my participation in the threads you start is that messages are very long, mix many different issues, and include both general concerns, such as MI syntax backwards compatibility, and low-level details, such as minor grammar optimizations. (And on top of that, top-post style makes the messages even longer and harder to read for someone who, like myself, has only a couple dozen minutes on a random day to read them.) So how about if you start several separate threads, one each about a specific MI issue out of those which are general enough for the global maintainers to participate? For example, this list: > 1. Can the mainline version get tagged asyncronous commands at the least? > I would prefer every command to have a tag. > > 2. Can there be a discussion about backwards compatibility with MI > output commands. This involves several issues I can think of. > 1. removing fields from an MI output command > 2. changing the output of an MI output command > 3. Making the commands themselves be backwards compatible even > between major releases. This essentially makes the MI output version > useless. already includes 2 separate issues that don't require too much MI-specific knowledge for any global maintainer to give you feedback. If you make the issues visible at the beginning, rather than buried at an end of a longish message, and keep different issues separate, I think we will have more hope to come to a consensus enough for you to craft a patch that has good chances to be accepted.