Losing Patches (was: embedded target breakage)

[Gerald Pfeifer <pfeifer at dbai dot tuwien dot ac dot at>]

On Thu, 21 Jun 2001, Geoff Keating wrote:
> I believe that a high proportion of patches sent to the list do get
> reviewed.

A *way* too high proportion, however, is missed.

For example, I have been offline for two weeks, and just while catching
up my mail backlog I noticed several such patches. And for every reminder
concerning unreviewed patches, I bet there is an equivalent number of
patches falling through the cracks silently.

> The problem is that if a patch gets missed, there is no way of keeping
> track of the backlog [...]

I disagree. Strongly. It just that processing patches by sending them to
a mailing list is an approach that proves itself less and less workable.

On Fri, 22 Jun 2001, Joe Buck wrote:
> I know that this is frustrating.  Patch reviewers get overwhelmed and
> things slip through the cracks that don't match the priorities of the
> developers, which, for 3.0, was to meet the release criteria as much as
> possible.  Because of this, it is necessary to be persistent.

It would be much better to do what the FreeBSD project, for example, has
been doing for ages, and use a better system to deal with patches. And the
name of one such system is -- GNATS! :-)

What I suggest is to do is:

 o Basically, we continue as we have been doing since the early egcs days.

 o However, if a patch has not been reviewed/installed for, say, two
   weeks, the submitter puts it into GNATS.

 o As a release criterion for every major and minor release (that is,
   GCC 3.0, 3.1, 3.2,...) we collectively try to process all such patches
   that have been submitted before a given date (like one month before the
   branch).

While not perfect, IMNSHO this approach is significantly better than what
we currently have.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/