[Python-Dev] tracker contribution

[Mark Lawrence]

On 18/07/2010 15:34, Antoine Pitrou wrote:
>
> Hello Mark,
>
> On Sun, 18 Jul 2010 00:45:09 +0100
> Mark Lawrence<breamoreboy at yahoo.co.uk>  wrote:
>> On 17/07/2010 22:57, Terry Reedy wrote:
>>> On 7/17/2010 8:41 AM, Mark Lawrence wrote:
>>>
>>>> IIRC Terry Reedy is also interested in moving IDLE forward.
>>>
>>> Interested, yes. But until either a) I can commit patches, or b) there
>>> is someone who will respond to commit review recommendations with "No,
>>> here is why not" or "Yes, committed", I will work on other issues, such
>>> as doc issues, for which I can get responses.
>>>
>>> I am certainly reluctant to recruit others to help, as I did for #9222,
>>> if there will be no action indefinitely.
>>>
>>
>> This is standard Python behavour.  The worst case I've come across is a
>> patch that dated back to 2001 that had not been dealt with.  But I'm
>> staggered as to how a third party supplies a patch for (say) 2.3, it
>> doesn't get applied, then the issue tracker simply keeps updating the
>> version targeted until we're now at 3.2.  That of course doesn't mean
>> that anything will get done, better wait until py4.7?
>>
>> My approach is very simple, maybe even ruthless, but in the long term I
>> believe it's better for everybody.  Does this patch stay open, yes or
>> no?  At least it gets the mind focused.
>>
>> Some people have complained at me about my approach.  Others have said
>> great job.  Obviously there's no correct or incorrect way, there's nowt
>> as queer as folk.
>
> Well, I would still encourage you to adopt a different approach.
> Simply bumping up bugs without adding any useful content to the
> discussion does not help much. Especially if you do so several times in
> a day, because it increases a lot the bandwidth of messages we have to
> deal to. And, given we have a limited amount of time and cognitive
> capacity to devote to Python (we're all volunteers), that means we
> either spend a lot of time reading your messages and context switching
> between several issues per day, or start filtering out your messages in
> order to stay focussed. And if we start doing the latter, it means you
> are just wasting your own time.
>
> It would be IMHO much more useful if you concentrated on a
> couple of issues which interest you, or which you feel competent in,
> and where you either:
>
> - produce a review of a posted patch
> - post a patch yourself
> - give suggestions as to how the issue could be solved (or,
>    alternatively, explain why it is detrimental, or useless, or too late
>    (etc.) to solve the issue)
> - ask questions to the original submitter if things seem fuzzy
>
> It is especially useful if you manage to produce a negative review,
> that is point out something wrong with the patch/issue. Things that can
> get wrong with a patch (non-exhaustive list follows):
>
> - the patch doesn't apply cleanly anymore (on the py3k or 2.7 SVN
>    branch, depending on whether the issue regards 3.x or only 2.x)
> - the proposed solution breaks compatibility in an obvious or subtle way
> - the patch lacks unit tests
> - unit tests don't adequately test behaviour (too strict, too laxist,
>    too fragile, etc.)
> - portability problems, i.e. patch wouldn't have guaranteed or proper
>    behaviour on all platforms
> - inconsistent or improper coding style
> - performance problems on arguably performance-critical code
> - undesireable side effects
> - etc.
>
> I would stress that this kind of involvment would also be able to get
> you much higher on the learning curve than your current involvment does:
> i.e., non-trivial contributions will build the competences to improve
> both yourself (assuming that's something you're interested in) and the
> complexity, correctness and completeness of your future contributions.
> Which in the middle-term is generally quite gratifying.
>
> Regards
>
> Antoine.
>
>
  I'm extremely offended by your comments.  I'll just back off and let 
the number of outstanding bugs grow and grow and grow, until such time 
as people get fed up with Python and go to (say) Ruby.

Kindest regards.

Mark Lawrence