This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: So let's get right to the point


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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]