[Python-Dev] Removing IDLE from the standard library
Jesse Noller
jnoller at gmail.com
Mon Jul 12 02:50:02 CEST 2010
On Sun, Jul 11, 2010 at 8:22 PM, geremy condra <debatem1 at gmail.com> wrote:
> On Sun, Jul 11, 2010 at 3:38 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> On Sun, 11 Jul 2010 14:59:14 -0400
>> Glyph Lefkowitz <glyph at twistedmatrix.com> wrote:
>>>
>>> Guido proposes to give someone interested in IDLE commit access, and hopefully that will help in > this particular area. But, as I recall, at the last language summit there was quite a bit of
>>> discussion about how to address the broader issue of patches falling into a black hole. Is
>>> anybody working on it?
>>
>> I think the best way to "work on it" is to work on having more core
>> developers, possibly with a more diverse range of interests.
>>
>>> (This seems to me like an area where a judicious application of PSF funds might help; if every
>>> single bug were actively triaged and responded to, even if it weren't reviewed, and patch
>>> contributors were directed to take specific steps to elicit a response or a review, the fact that
>>> patch reviews take a while might not be so bad.)
>>
>> The operative word being "judicious". It is not obvious who should get
>> funded, and for what tasks.
>> Some specific issues (like email in 3.x) are large enough that they can
>> be the sole focus of a fund grant. But I'm not sure triaging can apply.
>
> I'm mulling over starting a monthly triage sprint under the auspices of
> Jesse Noeller's PSF sponsored sprints in the hopes of making this a
> little more fun. I'd appreciate comments on the idea.
>
> Geremy Condra
Well, I'd like to get the sprint "how to" docs in shape, and then yeah
- we can totally do this. The sprints focuses were designed to help
with this pain (as others have pointed out) as well as other pain
points we've seen. Also note, hosting a "virtual sprint" or something
like that, which the sponsored sprint group simply helps advertise and
promote can help with this as well.
It's important though, when looking at triaging to keep in mind:
Moving the bug around (reassigning, etc) is of minimal use in a fair
number of cases - now, making sure it has a reproducible test case
(and can be reproduced), making sure the broken platforms are
enumerated, that patches have tests and docs (and are based on the
current trunk/whatever) and so on are much more valuable in the long
run.
Just some food for thought - and something to keep in mind if and when
we get to document more of this/etc.
jesse
More information about the Python-Dev
mailing list