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

[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

> > > > - 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.


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

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