Aegis one last time (was Re: [Bf-committers] to make or not to make)
Wed, 30 Oct 2002 20:17:48 +0000

On Wed, Oct 30, 2002 at 12:20:53PM -0500, Ryan C. Stallings (beergeek) wrote:
> Also on an unrelated note I think we need some sort of CVS policy (at least 
> until we get module owners).  CVS patches should be sent to the list for 
> review before committing.  Group consensus should be achieved before commits 
> occur (or at least no large opposition).   Peer review is an important part 
> of keeping the quality of an open source project high.

I'd like to point out one last time that this is exactly the process that
the "aegis" software (replacement for CVS) enforces. If we were using aegis,
this would have been the process:

1) The developer starts a new change on the local machine, changes files,
builds it, then "commits" it locally (this is called "integration" in aegis)
2) The developer submits via e-mail the aegis patch (in aedist format) to the
aegis server. (This is like "cvs commit" except it has to be human-reviewed
3) A procmail filter on the aegis server unpacks the patch in a new directory, 
tries to merge it with any other changes that happened in the meantime, tries
to compile it, and if all this works, moves the change into a "review" state.
4) A human sees the change in a "to be reviewed" list, then reviews the change,
recompiles it manually, then commits it permanently to the baseline
5) Other developers download the new change to the baseline (like a "cvs update")

The key part is that the baseline (the master copy of the sources) is never
changed without going through the review and integration process.

If anyone is interested in this, I would need help from someone at
(Hans?) in setting up an Aegis server. Developers would also need then to use
Aegis (instead of CVS) locally.

We could test-run an Aegis server too just so that people can see how it works,
get used to the process, and if it is worth pursuing. is Aegis' home page.