[Freeciv-Dev] Re: It is feature freeze time

["Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>]

At 09:07 PM 02/04/27 +0200, Per I. Mathisen wrote:
>On Sat, Apr 27, 2002 at 01:34:55AM +0200, Per I. Mathisen wrote:
>
>On Sat, 27 Apr 2002, Ross W. Wetmore wrote:
>> The "train leaves the station" model only works well in a branched
>> development environment. The methodology is to pick a stable base,
>> develop features independently off that base until they are ready
>> for integration, then periodically do a baseline integration of all
>> feature branches that are *ready*. Once the integration is stabilized
>> everyone syncs their outstanding feature branch to this milestone
>> and starts a new cycle.
>
>Sounds like total overkill to me. Please give some examples of projects
>where this methodology is being used with success. The free software
>projects I know that use branches, use this only for large, experimental
>code departures.

Free Software development typically uses CVS which is a primitive tool.
It is only marginally better than no tool. This leads to primitive or
non-existent forms of software development - look elsewhere for examples.

Other terms for this mode of development are "build levels" or "incremental
build process". Most corporations with reasonably advanced software 
engineering development models use a form of this. 

The major advantage is that it produces periods of stable baselines for
development (which is what most developers do anyway when they take a 
snapshot and work on it for several weeks before resyncing updates) with 
early incremental updates of completed features or feature elements that
enables better tracking of the overall project progress and chance for
early testing/workout of supporting elements.

>The only place where I can see that this could be warranted for freeciv is
>if we wanted to allow some poeple to rewrite the server-side ai while not
>touching the old server-side ai until the new one was ready. I think the
>corecleanups is the kind of thing we should _not_ do in a separate branch.

The corecleanups is by now a collection of a number of outstanding patches
with a lot of patch dependencies. If such patches were going into CVS on
a regular basis, then 1) there would be a lot fewer of them, 2) it would
not be difficult to maintain separated patches, 3) if there was active
discussion and movement on any particular feature it would be worthwhile
maintaining it as a separate CVS update (which is what Rahul and others
have done on occasion). 

The corecleanups are useful because they *work* with a minimum of fuss.
Maintaining each patch separately in the absense of any reason for it 
would be a nightmare for all and destroy the main ease of use quality :-).

Until there is real interest and commitment, they primarily serve as 
a sample self-contained tested and workable environment to show people 
what is possible, as well as an environment I find more interesting to 
play :-).

>That would mean everyone other than the author would completely lose the
>ability to understand what changes have gone in, because the changes
>become so many, different and complicatedly interrelated.

Generally, you pull out widespread supporting elements to a feature as
a separate pre-patch to let others see what changes might affect them
during discussion/review. But most of a feature should not overlap other 
areas and is relatively self-contained. Most people ignore changes not
relevant to their area of the code anyway. 

There is also nothing stopping people from looking at any parts of a 
patch - if you want to know you need to invest time reading and/or 
asking questions. Using the "I won't know" argument to limit change 
on a pure volume basis is a poor way to carry out development. It is 
better to implement practices to deal with the volume. Triage based 
systems, which is what branch development fosters, are the best ways
to deal with this. The pattern is divide and conquer ...

Note the corecleanup is not "a" feature or patch. It is a collection of 
features. The complications are a result of not doing incremental build 
updates as features are ready, and hence accumulating a volume backlog.

>Branching off a stable branch and continuing development on the main
>trunk, that is a concept I can understand. But giving each developer his
>own branch? I've never seen nor tried anything like it.

HP is a company that actually forces each developer to do all development
work on their own branch. German companies are even worse process addicts.

But you misunderstand. The branches I am suggesting are per "feature" 
or even per feature area (i.e. an AI branch, a sound branch, an agents
branch, a topology branch, a civworld branch, a miscellaneous bugfix 
branch). Such branches with an assigned suppporting maintainer, or 
limited commit ability for active developers would result in a lot 
more movement on the develpment side. The mainline is protected by 
making sure that the supporting maintainer vets and clears all 
integration point patches before they are passed off for mainline 
inclusion. The integration review stage should be relatively quick 
and more for information dispersal than development cleanup.

Having more than one developer working from a branch makes for better
and earlier detection of bugs and a more careful attitude. But having
a lot of developers doing this on a lot of different areas just makes
for undue noise - at least until the next stage of the process when
things are more stable and wider integration is desired.

The "Test" branch is a step in this direction, but lacks the support
on the mainline integration points and a more rigorous/frequent 
patch update schedule of well defined milestone elements. A better
way to share and coordinate outstanding patches between different
branches is also needed.

Note in developing a feature, is is often useful to build supporting 
elements and complete it in modular stages. There is no reason not to
merge supporting elements that have general impact or usefulness on
a regular basis at the build integration points. The criteria is that
these are self-supporting, pretty much complete and tested subunits.

The two map.c and city.c cleanup patches submitted in January were 
examples of support level patches.

Build levels typically occur every 6-8 weeks in real shops, but a
3 month cycle would not unreasonable for freeciv.

You can also limit what goes into the integration build when a release
is pending. This does not stop all development though and just means 
that the scrutiny or bar for integration patches has a higher threshold 
of shortterm concern than normal :-).

What you don't do, and something that CVS in particular makes impossibly
complicated is merge partial updates and hacks on a regular basis so
you keep the mainline in a constant state of turmoil, or conversely
freeze almost all (mainline) updates except for a few chosen features
so you maintain controlled stability for pet feature development.

The latter practices mean you are hitting the limits of your development
model and choosing to regress to a more immature one rather than evolve
to meet your real needs.


>I can see your point.

This is an important and good point to see expressed. You don't have
to always agree, but understanding the position and communicating this
fact reduces the noise level and means one can move on to resolve the
differences, or agree to disagree until such differences need to be 
resolved. Kudos to you.

There is a story about a merchant and a donkey, where the merchant 
always precedes a command to the donkey with a whack of a 2x4. When
asked the reason he said ... to get the donkey's attention.

Communicating signs that attention is being paid and an effort is being
made to understand a different viewpoint reduces the need for 2x4's :-).
Some groups/people are more responsive or receptive to differing ideas, 
and thus don't need the extra prods.

>Yours,
>Per
>
>Ask not what you can do for your country
>Ask what your country did to you
> -- KMFDM, Dogma

Cheers,
RossW
=====