[Python-Dev] Tracker archeology

[Brett Cannon]

On Thu, Feb 12, 2009 at 16:22, Stephen J. Turnbull <stephen at xemacs.org>wrote:

> 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.
>

I was aiming toward Daniel's issue of whether the bug could be reproduced
and thus verified as an issue when it is an old issue. But hopefully that
won't happen too often so adding a new stage is probably a bit much.


>
>  > 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.
>

It's a question of whether we can stay on top of updating issues or not. If
we can actually stay on the ball and update the status of issues then having
the OP update something shouldn't be needed as that is too easy of an
oversight for a casual contributor; minimizing the burden on contributions
by making the issue workflow easy for the contributor and efficient for us
is the top priority, but I think it is reasonable for us to do a little bit
more to make it easier on others.

And while you are right that the test/patch/doc stages can be view more in a
parallel fashion than the linear one the stage drop-down provides,
specifying the easiest of what is needed should help get more people
involved. Plus they are in the order things should be done in the ideal
situation.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20090212/4cbdd754/attachment-0001.htm>