[Python-Dev] how can I review? [was: Encouraging developers]

["Martin v. Löwis"]

Jim Jewett schrieb:
> It has been quite a while since I worried about my own patches going
> stale; I just want to know how my review time can be more useful.
> 
> Once a committer has already decided to look at a patch, comments may
> make the next step easier.
> 
> But is there anyway to flag an issue as either ready for that look, or
> already judged not-yet-ready?

Not in the current tracker, no. There is the "accepted/open" state, but
we use it to indicate "just needs committing"; if a reviewer doesn't
have the authority to actually approve the patch, it would give the
submitter the false impression that the patch will go in (which it 
might, depending on whether the committer agrees with the review).

> I had assumed that doing this patch-at-a-time would quickly get
> annoying.

To some, perhaps. However, they should unsubscribe from python-dev
if they get annoyed. As glyph said: this is the list where patches
should be discussed.

I can see why automated messages shouldn't go to python-dev; if
python-development-related hand-written messages annoy people,
they clearly subscribed to the wrong list (these days, some of
them better subscribe to python-ideas).

> Is batching several patches together part of what you want?

Not sure I understand. You mean several related bugs/patches?
I tend to look at patches for a single module often at one time,
in particular to find out whether they overlap or conflict, and
what the best order to apply them would be. Often, submitters
will have to redo their patch if a conflicting one is applied,
so here batching is important.

If you mean "do I work on python patches in batches?", then:
sometimes. I tried "a bug a day" for some time, but couldn't
sustain it. At the moment, I have some free time at hand, so
I look at many patches.

If you have a list of patches to be rejected, this could be
easily batched (rejecting is more easy than applying). For
committing, I still need to understand the issue in detail,
and the proposed patch. Of course, I would hope that the
review already lays it out so that it is more easy to understand
pros and cons, and that it will give information that the
submitter omitted (mostly because it was clear to him), so
for trivial patches, batch-committing them is feasible.

> (If so, I would personally still rather that the tracker or at least
> a wiki page did that grouping.)

Sure. I just created

http://wiki.python.org/moin/PatchTriage

Feel free to add patches there (if you want to, along with a date
on which you added it)

>> (I think a second
>> check is still needed, as the case of splitext shows: you were in
>> favor of rejecting it because of the incompatibility, ...
> 
> (I think that was actually John J. Lee; I did just add a note that it
> should no longer be considered bugfix candidate for 2.4)

Oops, sorry, confusing different JJs here (this may have happened in the
past also, I guess).

Regards,
Martin