Complete.Org: Mailing Lists: Archives: freeciv-dev: December 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: Sun, 2 Dec 2001 13:01:24 -0500 (EST)

> > > I didn't realize you were held off by the discussion.  I didn't like
> > > your API but it's a lot better than what we have.
> >
> >    Other than the various typecasting issues, what didn't people like
> > about it?
>
> I remember a proposal in which there was no syntax parsing, only chopping
> off words and feeding the rest to a callback, which made it hard to
> maintain a consistent syntax.  However I'd have to look at the actual patch
> for details.

   The callback would have depended on the first word in the command line.
Thus the 'for' or 'foreach' callback would have gone to one particular
function that went all-out for script parsing.  Similar things could have
been done in the 'set' or whatever callbacks.  I argued that my method
provided both speed and flexibility for those who wanted complex as well
as quick-and-dirty simple stuff.

> >    The other issue was that after several submissions of the split() patch
> > from me to no avail and one submission of another (identical) split()
> > function that got essentially lots of enthusiastic comments, I threw in
> > the towel for the time being.
>
> This is simply because the other patch was short and therefore easy to
> comment on.  In other words, it grabbed the attention of people like me
> with a short attention span.  It has nothing to do with the quality of
> the code.

hopi:~$ wc public_html/public/freeciv/split-stdinhand-cvs.patch
      77     379    2535 public_html/public/freeciv/split-stdinhand-cvs.patch
hopi:~$

   77 lines and less than 2.5KB is too long to review? (a good number of
which were comments)

> > I was starting school/research again, and
> > didn't have time to argue the finer points of why my solution fit the
> > problem.  I had code that did *exactly* what was necessary, but it got
> > completely bogged down in (IMHO) stupid memory management issues.
>
> Yes, and the management issues arise from the fact that too few people
> actually review patches.  (I don't.)

   I review patches when I have the time and they're something that's up
my alley.  Unfortunately the school year has depleted the former, and the
latter is contrained by what code I've read through.  But I do intent to
devote more time to putting my money where my mouth is.

> > It's hard when there's only one visible maintainer (and I do appreciate the
> > incredible effort that Raimar puts in), and they don't agree with you, and
> > you just *know* that you're right.
>
> Yes, the only solution is to have more maintainers (some have been asked)
> or open up CVS write access to anyone with a patch.  I have little
> experience with this but opening a second development branch for this
> purpose seems to be a proposal with little cost.

   I think the latter is a bit overboard, but I think it should be opened
to anyone who has demonstrated a good amount of knowledge of one
particular part of the codebase as opposed to all of it (aka, "Hi, I'm
John, the map generation unstable maintainer!").

-jdm

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



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