[Python-Dev] Tracker reviews workflow and flags

[R. David Murray]

On Fri, 19 Mar 2010 10:09:16 +0200, anatoly techtonik <techtonik at gmail.com> wrote:
> I want to push some of my patches before 2.7 and use 5-1 rule for
> that, but I can't come up with any review workflow other than mailing
> status of my comments to the issues here. I can't mark issues in any
> way. How about giving users ability to set flags or keywords? Maybe
> entering a separate field like "Review status"?

With our current workflow, mailing the status of your reviews here is
pretty much the only option.  ("I've reviewed issues a, b, c, d, and e,
could someone please review y?").

> Real world example with issue8151. It is an issue with a trivial patch
> in it. Everything what is needed is to dispatch it to stable `commit
> queue` and port to trunk. It is not 'easy' - it is 'trivial', but I
> have no means to mark it as 'easy' either, so even this trivial fix
> lies in tracker for three days waiting for review.

Three days?  That's nothing :)

> About 'easy' flag:
> "6	easy	This is an easy task (e.g. suitable for GHOP or bug day beginners)"
> It seems that it is for the issue that requires a patch, but if the
> patch is already there and nobody wants to commit it - what should I
> do?

If an issue has a patch the 'easy' flag doesn't really apply any more,
but it doesn't always get deleted, either.

Issues that have a patch should get set to "patch review" stage, unless
tests are missing, in which case it should get set to "needs test".

Making changes like that (and also updating keywords) requires tracker
privileges, but we give those out more freely than we do commit privs.
You could try hanging out on #python-dev on Freenode, where there will
(usually) be people who can respond to your requests to update the status
of tracker issues.  Make enough good requests and we'll get you tracker
privs so you can do it yourself.  ("Enough" is probably a pretty small
number, by the way :)

> Finally, review queue proposal.
> To follow 5-1 rule, I need to review 5 issues, before mine is
> reviewed, so I need some help from tracker.
> 1. I lack expertise in certain areas (C/C++, Mac OS, etc.), so I would
> like to hide some issues under "Needs review" query, so they won't
> bother me (if too many people marked issues in this way - the stats
> may become a good reason for highly professional bug party)

To avoid issues involving C coding, try restricting your search to
'Library' issues.  There is C code in some library modules, but less so
than in the core ;).  It would be nice if you could search on more than
one component, but currently the interface doesn't allow that.  (You might
be able to do it by hand constructing a query string, I haven't checked.)

> 2. I need ability to set "Needs review" flag back. Some issues were
> once reviewed, but since then they've got modified and need further
> comments.  The need the review again. That means pushed back _into the
> end_ of patch queue.

I'm not sure exactly what the 'needs review' keyword is for, frankly :)
Talking about pushing things back into the end of the patch queue makes
the assumption that there *is* a queue.  There isn't, there's just the
set of open issues with patches that committers look at when they can or
when they have an itch to scratch.  Making a comment on an issue (such
as doing a review) generates an email to everyone on the nosy list and
to the python-bugs list (for those people who are subscribed), and thus
in a fashion brings the issue to the 'top of the pile' in some sense and
for a short period.  Often things happen to the issue when a comment is
posted, but not always.  As with everything else, it depends on whether
anyone has both the time and the interest to take action.

> 3. Setting bug dependency by users. Often nobody wants to care about
> issue, because it is just too long, there is much irrelevant comments
> and nobody has time to read it. We don't have personal digg-like
> comment filters to cope with the amount of text to be brain-loaded.
> But it is possible to refactor such issue thread into separate
> digestable issue/issues.
>
> P.S.  About personal comment filters if anybody is interested in that.
> Digg-like +1, -1 are good for voting, but for filtering it would be
> nice to: 1. have several filters for different aspects of the thread,
> 2. have JS filter by marking individual phrases in comments and adding
> ranges to filter using jquery / ajax

-1 on comment filtering.  The text in the issue is the history of the
issue.  Reading it is part of doing an issue review.  I can't imagine that
the effort of manually blocking certain comments so that you didn't see
them when later looking at the issue again would be worth it.  It seems
to me you'd be much more likely to accidentally block something you should
be reading than you would be to make the issue usefully more readable.

If an issue needs to be refactored, new issues can be opened with
pointers to the old issue, and pointers added to the old issue to the new.
This can be done by anyone just by saying, eg: 'see issue 1234' (roundup
turns that into a link), and you can also suggest that the bug be added
to the dependency list by someone who can, if that is appropriate.
This happens fairly regularly with complex issues, or issues where we
discover more than one bug is involved.  Of course, it doesn't always
happen when it should.

The roundup code lives in the SVN repository, and you can set up your own
instance of the tracker to experiment with changes.  Patches are welcome,
although we have a few in the meta-tracker[1] already that haven't been
reviewed.  Currently Martin is pretty much the only one doing code-level
tracker work, and while I hope to get involved in that at some point it
hasn't happened yet.  So if you want to contribute some time in that
area, that would be great.  You could join the tracker-discuss list
(though it is very low volume).

[1] The 'report tracker problems' link on the lower left, if you
haven't noticed it.

--
R. David Murray                                      www.bitdance.com