[Python-Dev] reviewing patches

[Brett Cannon]

On Mon, Mar 9, 2009 at 20:55, Terry Reedy <tjreedy at udel.edu> wrote:

> Martin v. Löwis wrote:
>
>> I have seen it said that one very useful activity is reviewing patches.
>>> Of the issues in the tracker, it is not immediately clear to me what is
>>> required of such a review. Many of these patches appear to be bundled in
>>> with feature requests, leaving the question of whether the review it
>>> judging the quality of the code or the merits of the feature request.
>>>
>>
> Both may be needed, depending on the issue.  But see below.
>
>>
>> That's correct.
>>
>>  I
>>> do realise that these issues have probably been previously discussed on
>>> this list. Let's take as an example the following issue:
>>>
>>>  http://bugs.python.org/issue1818
>>>
>>
> Briefly, as I read it: Raymond proposed that his named tuples be used with
> Barry and Skip's csv module.  He got a short reply from Skip but went on to
> other things.  A year later, two new people entered and energized the
> discussion, Barry said 'useful', Skip commented on the details.  The second
> half of the discussion has been thrashing out and getting consesus on the
> devilish details.  What is devilish is that the merits of feature details
> sometimes interacts with code quality.  This is pretty typical.  It looks to
> me like this will be in 3.1.
>
> > often discussion is carried out entirely in the tracker (and
> > if you aren't on the nosy list of the issue, you will miss the
> > discussion completely)
>
> Every Friday a list of opened and closed issues is posted.  Even if you
> have nothing to say, you can add yourself to the nosy list.
>
> >> I feel a lot more
> >> qualified to evaluate code quality than desirability of function.
>
> Good, in the sense that I believe the former is rarer and more needed.
>
> There are 5 broad areas covered in the tracker:
> 1. C code, interpreter core
> 2. C code, extension modules
> 3. Python code, modules
> 4. Tests of the above
> 5. Documentation of above
>

This is somewhat covered by components, but it's implicit. Would it be worth
making this explicit? I have always wondered if people would be more willing
to help out if they could easily search for pure Python code issues if that
is as far as they feel comfortable. We could then have the components merge
into keywords or just take out the implicit type of issue part.

Or we just don't worry about auto-assignment. I think Georg is the only one
getting auto-assignment and I think we all know to assign him doc stuff. =)

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20090309/c3dda599/attachment.htm>