Complete.Org: Mailing Lists: Archives: freeciv-dev: November 2001:
[Freeciv-Dev] Re: Documentation, Usability and Development
Home

[Freeciv-Dev] Re: Documentation, Usability and Development

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Freeciv Developers <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: Documentation, Usability and Development
From: Justin Moore <justin@xxxxxxxxxxx>
Date: Thu, 29 Nov 2001 17:21:22 -0500 (EST)

> > > > - Increasing the number of nations
> > >
> > > I have made a patch. I was lazy and haven't added backward
> > > compatibility. If this wasn't the case the patch would be
> > > applied. Feel free to do add the backward compatibility.
> >
> >    I hate to say this, but at some point we really need to break backwards
> > compatability with the older cruft.  If we get a development tree and can
> > do one release with that, I think we should think long and hard about
> > starting to make a clean break to a 2.0 release.  Just like apache made
> > some serious serious changes to their architecture with 2.0, I think we
> > should, too.  Any questions about the evils of backwards compatability?
> > Just ask Intel. :)
> Yes, but IMHO this is not the case. It should be easy to introduce capability
> for this, so why to break the compatibility for this?

   Let me clarify a bit. :) When I said that we need to break backwards
compatability, I should have been clearer in saying that it was a general
statement, and not aimed at the number of nations at all.  I meant in
terms of some of the server architecture, string parsing, and various
other useful things that get held back because they break backwards
compatability.

> > > > - Server overhault
> > >
> > > This is too general. The unification is a good idea but I have seen no
> > > patches.
> >
> >    I sent in some huge patches, but several people complained about it,
> > saying that I had actually written code^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H
> > not thought out the design enough and their whiz-bang paper tiger was
> > better.  Since then I've heard nothing about it.
> Huge patches are bad idea, approval chance near zero, IMHO.

   Yes, but in some cases they're the *only* way to do something.  If I'm
ripping a 300 line function out of one file and creating a new one with
that function in it, there is *no way* I can do that in less than 600
lines.  A patch should be the correction or improvement of one aspect or
concept; if that aspect is already huge, then

1) one should wonder how the hell it got in there in the first place, and
2) it really needs to be fixed.

-jdm

Department of Computer Science, Duke University, Durham, NC 27708-0129
Email:  justin@xxxxxxxxxxx



[Prev in Thread] Current Thread [Next in Thread]