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

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

At 02:46 PM 02/04/28 -0500, Tony Stuckey wrote:
>On Sat, Apr 27, 2002 at 01:59:37PM -0400, Ross W. Wetmore wrote:
>> But most developers spend their time working on individual feature
>> branches in this model. And maintainers really don't seem capable
>> of integrating more then simple bugfix patches or completely new and
>> separate code hierarchies given the past year's experience as example.
>> Both these elements would have to change.
>
>       Guilty as charged.  I freely admit that I do not have a
>sophisticated understanding of how to use all the benefits of CVS.

It is not actually CVS expertise that is required. It is more policy
management decisions to support branched or parallel development
streams vs an ongoing one true CVS free-for-all approach. I actually 
have suppressed most of my CVS work experiences as nightmare times I 
don't need to or want to remember, so I tend not to think of it as
any critical component :-).

It would be nice to have all branches on freeciv.org under the same
CVS repository as distinct variants, with easy patch merging etc.

But it is still perfectly reasonable to have a SourceForge Testbed,
a Bohemian AI development group in some loft somewhere, and TeamCiv
or other groups with their own support and infrastructure. They 
could all submit quality patches for periodic integration builds
without needing direct access to the freeciv repository.

What is needed is better management of the CVS mainline, with an
agreement to accept larger more polished patches less frequently,
i.e. on a periodic basis. Freeciv maintainers probably want to 
manage a bugfix branch separate from the mainline to collect the
smaller patches on random submissions, more or less like the current
model, and do only a periodic update at the integration points along
with the more substantial feature work.

Having to do such merge integrations only periodically with a lot of
the individual patch integration and testing handled by the integration
build cycle to produce the next stable baseline, i.e. just one single
big merge update vs the death of a thousand cuts, would make branch
maintenance doable. Having current patch snapshots vs a stable baseline 
for different branches centrally available, would allow cross mixing
and co-development between integration points on an as desired, vs 
forced basis.

Branches would also be able to submit feature extension patches that 
would have known respectable lifetimes. If freeciv.org helped manage 
this process by hosting a past release, current release and dev-integration 
points since last release patch storage, with possibly tested and untested
(i.e. sanctionned and unsanctionnned) directories it might perhaps foster
more and better independent patches which could be curried and dealt
with by the inclusion processes. These would be reworked and published
accordingly, with a schedule of deadlines for the next train departure.

The difference between a supported or included patch and one that has
not been accepted or placed on the acceptance path, is largely who and
how much ongoing maintenance is needed to keep it current. The periodic
releases will serve to flush older obsolete material that is not 
actively maintained by someone.

I think maintainers would be useful to manage feature or area branches
which Freeciv management has deemed needing more ongoing support or 
of particular priority - or for whom willing people are found, as the
case may be. 

One could also place limits and a certain peer review selection of external 
or non-maintainer sponsored patches with a quota limit to make a fair 
but controllable policy for dealing with things that arrive without 
official support (this does not include the ongong bugfix area). Thus 
projects move ahead if they have management approval, or through a known 
lottery and review process. The latter would serve to provide some 
incentive to encourage more widespread participation and innovation,
with quality submissions but without undue expectation or disappointment 
:-).

A big question is can the Freeciv maintainers, and/or their chosen
helpers turn around a half dozen or dozen major patch integrations 
every few months within a week or two of review and week of CVS update 
and final testing? Can they do/manage fair and impartial reviews?

Will there be a standard set of test procedures that evolve to insure 
that the result is usable and key elements aren't broken?

And can the maintainers keep their hands off the mainline to insure 
things remain stable over reasonable periods of time - i.e. follow a
reasonable schedule for doing all but absolutely critical things, and 
hit deadlines when needed?

Conversely will maintainers drop the excuse that a patch is "n" hours old
and therefore not usable against current CVS for them to even consider
wasting time on (which I will admit the current set of maintainers
makes far less use of than in the past, but which when used tends to
illustrate the differences in approach and style of a mature and immature
process environment :-).

>-- 
>Anthony J. Stuckey                              stuckey@xxxxxxxxxxxxxxxxx
>
>'Finally, the Navy stated that [...] "However, use of the area as a live
>fire range has the beneficial effect of reducing the negative impacts of
>human intrusion."' - Center For Biological Diversity v Pirie and Rumsfeld

Cheers,
RossW
=====