Re: patch database proposal

[Jim Blandy <jimb at cygnus dot com>]

>    Here's a tentative proposal for how the patch database should work.
>    In reality, a good part of this is set up and ready to go, but there's
>    nothing we can't revise, in the presence of good ideas or persuasive
>    criticism.
> 
>    Please let me know what you think; post your comments to the list.
> 
> Looks good to me.  We'll probably want to phase out gdb-patches in
> favour of gdb-patches-prs.
> 
> It is hard to estimate the amount of work the patch secretary has to
> do, but if it's a lot, we could have multiple secretaries.  A bit like
> multiple maintainers but with the difference that all of them can work
> together.  GNATS locking should take care of avoiding duplicate work.
> 
> I think it should also be possible for maintainers to enter patches as
> `applied' by sending a *single* message, without the need of further
> manipulation of the database (to replace the current practice of
> maintainers sending a patch to gdb-patches for work they did
> themselves).

Yes, these are the two open questions:

- What happens to gdb-patches?  It seems to me that since gdb-patches
  is for conversations about specific patches (or we could define it
  that way), so it gets replaced by gdb-patches-prs.

- Given that every state change generates a message to
  gdb-patches-prs, is it possible and convenient to keep the number of
  messages down to the minimum necessary?