Complete.Org: Mailing Lists: Archives: freeciv-dev: August 2001:
[Freeciv-Dev] Re: Introduction and Patch Approval Process
Home

[Freeciv-Dev] Re: Introduction and Patch Approval Process

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx
Cc:
Subject: [Freeciv-Dev] Re: Introduction and Patch Approval Process
From: col@xxxxxxxxx
Date: Thu, 16 Aug 2001 10:23:12 +0200

Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx> wrote ..
> On Wed, Aug 15, 2001 at 04:56:40PM -0700, Roy Tate wrote:
> > Hi,
> >   I've been playing FreeCiv for a few months, and monitoring
> > the development mailing list for a few weeks now.  I just
> > downloaded release 1.12.0 and did a make on TurboLinux 6.5.
> > I'll probably read the source code over the next few months,
> > and then start helping with patches and patch reviews.
> > 
> > I have been programming in C, C++ and Java for 5 to 15 years,
> > but up to now I have written for DOS/Windows most of the time.
> > 
> > I like the idea of a patch approval process:
> > 
> > 1) Developer submits a patch
> > 2) Someone is assigned as a reviewer
> > 3) Reviewer offers feedback on the patch
> > 4) If the patch is recommended by the Reviewer,
> >    it goes the list for discussion.
> > 5) If the patch is approved by one or more "core" developers
> >    with experience with the areas of code affected by the
> >    patch, it becomes a candidate.
> > 6) If 3 core developers approve the patch, it is submitted
> >    to CVS.
> > 
> > Reviewer's responsibility:
> > - Check code formatting and style, portability and correctness
> > - Apply the patch and test the code
> > - Respond with suggestions, corrections, rejection or approval
> > 
> > The "core" developer is an experienced developer who is familiar
> > with the code-base, and particularly with the area affected by
> > the submitted patch.  His responsibilities:
> > - Check the code just as a Reviewer would
> > - Apply the patch
> > - Walk through the code in a debugger or execute the code in
> >   a test program.
> > - Recommend approval, rejection or on-hold status
> > 
> > Note that the reviewer doesn't reject the patch, although they
> > might pass on such a recommendation to the developer.  Also,
> > please understand that the reviewer is also a developer, but
> > they don't have to be as familiar with the FreeCiv codebase. 
> > This isn't the whole process, but it is a start.
> 
> I'm not sure if a more formal approach is needed. IMHO just a bit more
> dedication of the readers of freeciv-dev and other people is
> needed. Look how many emails yesterday had come. If all the readers
> continue commenting like yesterday freeciv wouldn't have a problem.

Sure, yesterday was a good day for freeciv. I think it should be normal that 
all people comment a patch, so that the developper can make it perfect.

> However one thing you mention above would be helpful: each "core"
> developer should have an area of interest. This information should be
> published. This isn't to cut the mails to freeciv by sending the patch
> before to such a "part maintainer" but to have at least one person
> from which the patch submitter can expect a comment.

Yes, I think so. One question: One person said that there would be someone who 
has worked on a sound patch before but noone gave me an e-mail so I can work 
with him together... Could someone tell me more about some details of having 
sound in freeciv ( I am not very long on this list) so that I can improve my 
system ?

If noone is interested in being the "core" developper for sound, I would be 
kind if I could do it. By the way, I am also working on the alsa-drivers...

CU,
David

PS: I will send in a *perfect* sound patch in this weekend with an option to 
parse a sound config from a file (like the tilesets [ with the same macros]). I 
also found some sounds which really rocked when I played some hours yesterday!

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