This is the mail archive of the gdb-patches@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: patch management?



> I'm not familar with Gnats.  Ideally something like Clarify's work queues (hey
> put down those basebats....) where a patch waiting to be reviewed sits in a
> queue, and people can indicate that they are looking at the patch for those
> patches that take more than 2 seconds of time to evaluate (so that you don't
> have 3 people all looking at the patch at the same time) and/or approval.  It
> would be nice if it could work with multiple branches (and especially handle
> those things that go out into fsf, etc.), hopefully doing the checkin
> automatically.  As a patch reviewer, I want to be able to see all patches that
> are waiting for me personally to look at, and also patches that anybody in the
> group can approve.  As a patch submitter, I want feedback on outstanding
> patches.

The CVS stuff is a challenge.

But I think GNATS can do all the rest, just by choosing the right
conventions.  These conventions should be explained somewhere really
public, like on the GNATS query web page.  Every PR should have a
header named "State-explanations:" whose value is the URL for the web
page explaining them, so nobody forgets.

Here's a set of states which I think could do the job.  Do you think
these would work?

State: unclaimed

    New patches come in in this state.  This is the "queue".  You can
    query the queue by looking for patches in this state.  People who
    decide they can't cope with a patch can put it back in this state.

    The "Responsible" person is responsible for assigning the patch to
    someone, but it's also cool to just grab a patch in this state.

State: assigned

    The person named in the "Responsible" field has volunteered (or
    been designated) to review the patch, but they either haven't
    looked at it, or haven't made any decisions about it yet.

    Note that there is no "examined" state --- a patch's examination
    is incomplete, by definition, until a decision has been made.  And
    at that point, the patch should be in "feedback", "rejected", or
    "accepted", indicating the decision reached.

State: feedback

    The patch is awaiting further explanation or revision from the
    submitter.

State: accepted

    The "Responsible" person has decided to apply the patch, and
    expects to do whatever further work is necessary (investigation;
    revisions) to get it into the sources.

State: applied

    The "Responsible" person applied the patch, and expects no further
    work on it is necessary.

State: papers

    The patch has been accepted, but is waiting for the copyright to
    be assigned to the appropriate holder.

State: rejected

    The "Responsible" person decided that the patch should not be
    applied, and is not expecting revisions or further work on this
    patch.  (Of course, it is always possible to resurrect a patch
    simply by putting it back in one of the other states.)

    This state is also used for the following situations:
    - the submitter withdrew the patch, and the maintainer agrees
    - the patch is so old it's gone stale, and is no longer useful in
      revising the sources, and nobody has any intention of revising it
    The notes for the state change should explain the circumstances 
    for its rejection.

    Perhaps someone can think of a less pejorative name for this state.

My intentions:

- Every state should have a person clearly responsible for the next
  step, except "unclaimed", whose whole purpose is to indicate that
  responsibility hasn't been assigned.

- Every state change should represent an externally significant
  event, like a shift in responsibilities or a decision, not events like
  "I've looked at it but haven't concluded anything yet", which have no
  external significance.

- It should be easy to remember.

I don't know if these states actually meet those criteria, but that's
what I was trying to do.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]