[Python-Dev] Tracker archeology

Stephen J. Turnbull stephen at xemacs.org
Fri Feb 13 01:22:56 CET 2009


Brett Cannon writes:

 > Sounds like a "*verify issue* stage is needed. Although I guess I kind of
 > assumed as part of the triage issue verification would happen as well, but
 > that might be too much as a single step.

Are you confusing "reproduce" with "verify"?  Remember, one of the
three classes for triage is "not a problem we need to deal with".
Reproduction really is the same thing as providing a test.

 > All the other ones can use the current stages (e.g. a missing test with a
 > patch is still at a *test needed* stage, it just happens to be able to skip
 > to review once that test is ready).

What I did with XEmacs's tracker (which has borrowed a lot from
Python's, thank you all *very* much!) is to have an "in progress"
stage, with "needs test|patch|doc" and "has test|patch|doc"
*keywords*.  The difference in semantics is that "needs" is a judgment
by the supervising reviewer, and the change (in theory) shouldn't be
committed until all "needs" are satisfied, while "has" is what the
contributor submitted.  So they are independent, and you could even
have both "has patch" and "needs patch" present if the current patch
isn't good enough.

This is too complex to expect people to execute, even IMO, but maybe
there's the germ of an idea there?  For example you could tell
contributors that if the "has patch" flag isn't set, the patch won't
get noticed by anybody.


More information about the Python-Dev mailing list