From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28370 invoked by alias); 21 Nov 2003 20:59:27 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 28353 invoked from network); 21 Nov 2003 20:59:26 -0000 Received: from unknown (HELO smtp804.mail.sc5.yahoo.com) (66.163.168.183) by sources.redhat.com with SMTP; 21 Nov 2003 20:59:26 -0000 Received: from adsl-64-175-251-31.dsl.sntc01.pacbell.net (HELO ?192.168.1.102?) (sampln@sbcglobal.net@64.175.251.31 with plain) by smtp-sbc-v1.mail.vip.sc5.yahoo.com with SMTP; 21 Nov 2003 20:59:24 -0000 Subject: Re: So let's get right to the point From: Lincoln Peters To: Xconq list In-Reply-To: References: Content-Type: text/plain Message-Id: <1069448359.12476.89.camel@odysseus.peterslan> Mime-Version: 1.0 Date: Fri, 21 Nov 2003 23:14:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2003/txt/msg00900.txt.bz2 On Thu, 2003-11-20 at 23:09, Brandon J. Van Every wrote: > So let's get right to the point. How many things that I propose, are > you going to obstruct out of your need for personal animosity? I think > it's best that you make the list now. That way, we don't have to waste > time with people talking about it, me implementing it, and you blocking > it. State your turf, the things you certainly aren't going to give > ground on. I had hoped that this arguing would be over by now, but you both still seem to get on each other's nerves. I'm not sure why. I'm not going to try to take sides, but I will try to answer some of these questions (although none of them make good multiple-choice questions). > > We'll make this partly a multiple choice test. > > 1. Python required in the kernel > a) yeah, that's awesome! > b) hell no. Go away. I don't think Python is required, but Python would make it easier to do things that are difficult or impossible right now (which have already been discussed over the last few days). And it might improve Xconq in ways that we can't predict now. The catch is that none of us want to add Python support to Xconq until other bugs are fixed (see #2). No matter how many cool things a game is supposed to be able to do, nobody will play it if it doesn't work. > > 2. Kicking 7.5 out the door so that new features can be added > a) yeah, any week now! > b) I want my months before you even think about touching my source pool. I think that it's quite clear that we all want to fix as many bugs as possible before releasing 7.5. Although it seems that we're getting close. Remember, open-source projects (usually) do not have marketing people screaming at them. Xconq 7.5 will be released when it is ready, and not a moment before. A lot of software companies (especially Microsoft) could have saved themselves a lot of trouble by working this way. I don't think that anyone is worried about you "touching our source pool" beyond that you might introduce something that has unexpected results. That's why anyone with CVS access tests a piece of code as thoroughly as possible before committing it. > > 3. Recruiting a horde of Windows C# .NET developers > a) the more the merrier! > b) get out of here you Micro$quish suckup bastard "Micro$quish?" That's a new one. I originally brought up Mono because I thought that it would make it easier to add components to Xconq in languages other than C. Although I suppose that it would make it possible to add lots of new features to the Windows version, I would be reluctant to add anything that would not work on all Xconq platforms. For example, I would be willing to add code to Xconq that would let it talk to MS Excel, but only if it was possible to do the same thing with at least one other spreadsheet application (e.g. Gnumeric) on other operating systems (e.g. Linux). My interest in Mono has nothing to do with its cross-platform nature, although it is a feature that could save us a lot of effort in the long run. If Microsoft pulled the plug on Ximian, Mono would not lose any of the features I originally pointed out. And I would expect it to be possible to maintain a separate implementations for Mono and .NET in a similar way to how we maintain separate interfaces now. Getting back to your question, if a horde of Windows C# .NET developers could make a contribution to Xconq without causing problems in the UNIX and MacOS versions of Xconq, I'd be inclined to welcome them. > > And, these are questions I expect firm answers to. The number of (a) > answers determines whether Xconq is a good use of my time. Are the answers I provided firm enough? By the way, I think that it would be worth looking your VS 2003 Solution files. I'll assume that they work reasonably well, as I doubt you would have said anything if they didn't work. Although that doesn't mean that we shouldn't test them before committing them to CVS. Is there anyone else on this list who has VS 2003 and would be willing to take a look at the files?