Re: gcc source management requirements

> >> 4) GCC, more than many projects, makes use of a formal review
> >> process for incoming patches.
> > Yes.

> This is a strength, but with a downside -- patches can and do get
> lost. We advise people to re-send patches at intervals, but some
> sort of automated patch-tracker would probably be helpful. I don't
> think the version control system can help much here (but see below).

I've started using the micropattern of putting all submitted patches
as diffs into a subdirectory of the CVS tree. As a small example:

  http://cvs.samba.org/cvsweb/distcc/patches/

This has a few benefits:

 - they're easier to find there than in a mail archive or somebody's
   hard disk

 - if an updated version is submitted it can be updated in CVS and
   tracked, so people can easily find the most recent revision

 - they can be deleted (and therefore "marked closed") when they're
   either merged into the main tree or obsolete

 - patches that are not generalized but perhaps useful on a particular
   platform or situation can be found and applied by people who need
   it

 - it's more motivating to people sending patches that it is at least
   "half accepted" rather than apparently ignored

 - you can add comments about the patch in commit messages or at the
   start of the patch

 - it's easier than setting up a separate patch tracking tool, and just
saving from a mail reader straight into a patches/ directory is quicker
than going through a web interface

I don't know if this would work for the (obviously much larger) gcc
project, but I find it useful.

-- 
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org