Complete.Org: Mailing Lists: Archives: freeciv-dev: August 2001:
[Freeciv-Dev] commit early, commit often (was: Submit patch again?)
Home

[Freeciv-Dev] commit early, commit often (was: Submit patch again?)

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx (Freeciv developers)
Subject: [Freeciv-Dev] commit early, commit often (was: Submit patch again?)
From: Reinier Post <rp@xxxxxxxxxx>
Date: Thu, 16 Aug 2001 10:11:56 +0200

On Wed, Aug 15, 2001 at 11:33:32PM -0700, Kevin Brown wrote:

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

OK.  (BTW, there's no need to argue that point.)

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

For me, it's a question of dividing attention between C code and the
other things that surround Freeciv.  (Playing ...)

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

OK, still it would help to give explicit instructions for testing.
"Start a game, turn off FOW, and move around the map a bit."
Dumb it down to the level of those who haven't seen the code.

> > Another problem is that patches get lost or outdated too easily.
> 
> This is because they're not being committed to CVS!

Not sure.  If they were in CVS (on separate branches?)
their status might be even harder to follow.
 
> 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).

Yes, the policy has been to keep the source tree stable and clean.
(Note: I'm just echoing what others have said here, I'm not a
core developer.)

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

Seems like a good thing to try ... some change is definitely required.
 
> Sorry for my long diatribe on the subject, but this seems an area
> where the deficiencies are rather obvious.  :-)

Thanks.

-- 
Reinier


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