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

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Thu, Aug 16, 2001 at 10:23:12AM +0200, col@xxxxxxxxx wrote:
> 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 ?

Somebody mentioned the FAQ: http://www.freeciv.org/faq/#QA26

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

Fine for me.

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

Good. That external sounds are needed.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "At the beginning of the week, we sealed ten BSD programmers
  into a computer room with a single distribution of BSD Unix.
  Upon opening the room after seven days, we found all ten programmers 
  dead, clutching each other's throats, and thirteen new flavors of BSD."