[Freeciv-Dev] Re: Submit patch again?

[Kevin Brown <kevin@xxxxxxxxxxxxxx>]

Reinier Post <rp@xxxxxxxxxx> wrote:
> On Wed, Aug 15, 2001 at 02:02:48PM +0200, Karl-Ingo Friese wrote:
> > I think this might be a quite healthy discussion. Hopefuly it
> > will bring up something good.
> 
> I hope the problem is to find a better procedure.  If the problem is
> manpower, I don't know how to address that.

I've been subscribed to the list for about 2 weeks now.  In that
period of time, I've seen some 90 distinct people post something to
this list.  Somehow I don't think manpower is the issue.


As a developer, feedback on a patch is CRITICAL.  It's the only way a
developer has any idea that he's doing something USEFUL.  It helps
enormously, of course, if the patch manages to make it into the CVS
tree.  There are other reasons that patches need to make it into CVS,
and I believe the CVS commit issue is the larger issue here.  See
below.

In any case, I have a suggestion for all of us: submit ALL patches via
the bug tracking system.  That way the discussion can be framed in
terms of the deficiencies that are being addressed by the patch, and
there's a permanent record.  It'll make referencing previous patches
FAR easier (just give the PR number).

> > For sure. Thue did very much for the freeciv project and I think
> > no one questioned that. Or to speak only for myself: I never did.
> > However, I described my personal feelings when I submitted
> > ideas or code to the mailing list.
> 
> Yes, I have the same feeling very time I see a patch, but the only
> patches I actually look at are those that are in "my" area of the code,
> which is very small.

You needn't be an expert on an area of code to have useful comments
about a patch.  It doesn't take that long to get your feet wet with
new sections of the code (I managed to do so for the GTK client's map
drawing capabilities in a day or two).  I'll admit that there are
parts that are fairly involved, but that's not true of all the code.

> > > In the Freeciv project, there are no 10 others.  It's hard enough to
> > > find 10 people with patches.
> > 
> > Its hard enough because there is no feedback. The only few times
> > I got encouraging and positive response yet were from active players
> > - not from active freeciv developers. But no, thats not true. The
> > new player dialog would not have been possible without the help of
> > Vasco (thanX again).
> 
> Doesn't this suggest that there simply aren't enough developers?

Maybe.  But the number of unique contributers to this mailing list in
just the past 15 days tells me that the number of developers isn't the
problem.

I have a suspicion: how many developers have CVS write access?  That's
where the bottleneck may be, because it's *those* people that have to
be convinced that a patch is worth something.  If a patch doesn't get
into CVS, it doesn't get into the releases, and nobody ever benefits
from it.

So perhaps CVS write access needs to be granted more liberally than it
is right now, with the understanding on the part of to whom it's
granted that part of responsibility that goes with the privilege is
that of examining patches submitted here and committing them.

> > > OK, this process could be streamlined by adding some web forms and better
> > > database support.  But the basic problem is: not enough people are willing
> > > to look at somebody else's code.  Am I wrong?
> > 
> > No ... I think the basic problem is that there is to less "hey, thats
> > a cool idea" or "this is already on our to do list but a little different
> > then the way you implemented it, look at section 3.1" or "I did
> > not like the idea because of xy" feedback. One of the reasons thatfor
> > might be that most freeciv developers/maintainers dont actively play
> > the game anymore.
> 
> This may well be.  Freeciv games take hours to play.  It would also help
> if patches were published with example savegames to demonstrate their
> features.

Perhaps.  I totally agree with the savegames submission idea, where
appropriate.  But there are lots of patches that don't require playing
a full game to determine whether or not the patch is worthwhile.  Take
my GTK+ client speedup patch (which I'll be releasing as a separate
patch dependent on the patch I supplied for PR#892), for instance.
The benefits of that patch are obvious simply by starting up the
client with the appropriate option to activate it and moving around
the map a bit.

> Another problem is that patches get lost or outdated too easily.

This is because they're not being committed to CVS!  And they're not
being committed to CVS because the people who have write access to CVS
don't manage to review all the patches being supplied, either because
they're not in their scope of expertise or because they don't appear
that interesting, or they don't have enough time (which is a strong
argument for giving CVS write access to more people).

In my little time here on the list, there's one impression I get that
seems to come through loud and clear: there is a great reluctance to
commit patches to the CVS tree, sometimes for the most trivial of
reasons (coding style, for instance).  If we want to keep developers
interested in the project, then this has got to stop!  Open source
projects such as this benefit greatly from having a large number of
people to look at and play with the fruits of the developers' labor.
We can't get that benefit by keeping patches out of the CVS tree!
It's bad enough that we expect people to grab the latest CVS snapshot
to play with.  Expecting those same people to also apply patches they
find here is completely unreasonable.  In fact, if we really want to
get the latest'n'greatest out in front of the most people, we should
supply daily binary builds along with the sources (I don't think we
already do that).

We should be willing to apply patches to CVS that may be questionable
so that the bugs in them can be ironed out.  I'm not suggesting that
we apply patches to CVS without doing a little testing of them or at
least giving them a cursory glance first.  But much of the initial
testing has already been done by the patch submitter (I've done days
of testing and refinement of my own patches).  Nobody here wants to
submit a patch that'll break lots of things, so we shouldn't be so
reluctant to apply them to CVS when someone supplies them to us.


I can't stress this enough: commits of patches to CVS are the *only*
way to make forward progress in the development of Freeciv.  So it
follows that it should be as easy as possible to get a patch into CVS.
If the concern is the integrity of the code, then remember that in CVS
you can create a fork and merge it back into the main tree later.  So
for particularly hairy patches we could, for instance, create a CVS
fork, apply the patch, create a binary distribution from the fork, let
dudes test it out and give feedback, and eventually merge it back into
the main line...or discard it if it's too difficult to fix.


Sorry for my long diatribe on the subject, but this seems an area
where the deficiencies are rather obvious.  :-)


-- 
Kevin Brown                                           kevin@xxxxxxxxxxxxxx

    It's really hard to define what "unexpected behavior" means when you're
                       talking about Windows.