Re: [Python-Dev] IDLE contributors and committers

On 7/17/2010 7:33 AM, Antoine Pitrou wrote:
Hello,
On Sun, 11 Jul 2010 02:05:22 +0300 Tal Einat <taleinat@gmail.com> wrote:
I would like to propose removing IDLE from the standard library.
I have been using IDLE since 2002 and have been doing my best to help maintain and further develop IDLE since 2005.
I haven't seen any conclusive statement or action to this thread. Without being an IDLE user myself (for good reason), I think that if IDLE should stay, active contributors such as Tal should be given commit access and enough free rein to maintain and improve it.
Otherwise there's no reason to continue claiming that IDLE is important while discouraging such people's contributions. The current situation, where several core developers support IDLE's continued inclusion but none actually cares for the issues and patches in the tracker, is schizophrenic.
Regards
Antoine.
+1 There's no reason why Tal should be obstructed in his goal of making IDLE at least acceptable again. It's fairly obvious thaat there aren't any committers who have both the inclination /and/ the time to do this, so adding Tal (and other interested parties) as a developer makes a lot of sense. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010 http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/

On 17/07/2010 12:47, Steve Holden wrote:
On 7/17/2010 7:33 AM, Antoine Pitrou wrote:
Hello,
On Sun, 11 Jul 2010 02:05:22 +0300 Tal Einat<taleinat@gmail.com> wrote:
I would like to propose removing IDLE from the standard library.
I have been using IDLE since 2002 and have been doing my best to help maintain and further develop IDLE since 2005.
I haven't seen any conclusive statement or action to this thread. Without being an IDLE user myself (for good reason), I think that if IDLE should stay, active contributors such as Tal should be given commit access and enough free rein to maintain and improve it.
Otherwise there's no reason to continue claiming that IDLE is important while discouraging such people's contributions. The current situation, where several core developers support IDLE's continued inclusion but none actually cares for the issues and patches in the tracker, is schizophrenic.
Regards
Antoine.
+1
There's no reason why Tal should be obstructed in his goal of making IDLE at least acceptable again. It's fairly obvious thaat there aren't any committers who have both the inclination /and/ the time to do this, so adding Tal (and other interested parties) as a developer makes a lot of sense.
Guilherme's *existing* patch for IDLE looks like it improves it a great deal, at the cost of potentially requiring Tk 8.5 (?). Can this just be committed? https://code.google.com/p/python-ttk/wiki/Screenshots Michael Foord
regards Steve
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.

On 17/07/2010 12:50, Michael Foord wrote:
On 17/07/2010 12:47, Steve Holden wrote:
On 7/17/2010 7:33 AM, Antoine Pitrou wrote:
Hello,
On Sun, 11 Jul 2010 02:05:22 +0300 Tal Einat<taleinat@gmail.com> wrote:
I would like to propose removing IDLE from the standard library.
I have been using IDLE since 2002 and have been doing my best to help maintain and further develop IDLE since 2005. I haven't seen any conclusive statement or action to this thread. Without being an IDLE user myself (for good reason), I think that if IDLE should stay, active contributors such as Tal should be given commit access and enough free rein to maintain and improve it.
Otherwise there's no reason to continue claiming that IDLE is important while discouraging such people's contributions. The current situation, where several core developers support IDLE's continued inclusion but none actually cares for the issues and patches in the tracker, is schizophrenic.
Regards
Antoine. +1
There's no reason why Tal should be obstructed in his goal of making IDLE at least acceptable again. It's fairly obvious thaat there aren't any committers who have both the inclination /and/ the time to do this, so adding Tal (and other interested parties) as a developer makes a lot of sense.
Guilherme's *existing* patch for IDLE looks like it improves it a great deal, at the cost of potentially requiring Tk 8.5 (?). Can this just be committed?
https://code.google.com/p/python-ttk/wiki/Screenshots
Michael Foord
regards Steve
IIRC Terry Reedy is also interested in moving IDLE forward. Some help will certainly be needed to work on the 3 high, 80 normal and 13 low priority issues that are open against IDLE on the issue tracker. Kindest regards. Mark Lawrence.

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. -- Terry Jan Reedy

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. Reminds me of Canned Heat, "Let's stick together". Kindest regards. Mark Lawrence.

Hello Mark, On Sun, 18 Jul 2010 00:45:09 +0100 Mark Lawrence <breamoreboy@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.

Antoine, You've just saved me from composing essentially the same message. I am top-posting because I have very little to add. Mark, I actually reviewed the issues that got closed thanks to your "bumping them up". That was 30+ issues over the last week or two. Quite impressive. However, I see you "nosy" on about 180 open issues. This raises a question about signal to noise ratio that Antoine mentioned. I would like to join Antoine recommending that you concentrate on issues that you are competent in. In addition, I think your breadth first approach is also valuable, but don't comment of every issue that you read. Unless you feel that the issue was simply forgotten (last message is from OP and no response from assignee or issue is not assigned), it may be better to move on when you don't have something meaningful to contribute. On Sun, Jul 18, 2010 at 10:34 AM, Antoine Pitrou <solipsis@pitrou.net> wrote: ..
On Sun, 18 Jul 2010 00:45:09 +0100 Mark Lawrence <breamoreboy@yahoo.co.uk> wrote: ..
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.

On 18/07/2010 15:34, Antoine Pitrou wrote:
Hello Mark,
On Sun, 18 Jul 2010 00:45:09 +0100 Mark Lawrence<breamoreboy@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

On Mon, Jul 19, 2010 at 4:43 AM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
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.
Please don't take it that way - Antoine and Alexander are just trying to help you make the most effective use of the time you spend contributing (which *is* appreciated!). In my case, I don't spend much time trawling the tracker for issues, so I'm reliant on other people kicking import related issues in my direction by adding me to the nosy list or bringing them up here on python-dev. I think a couple of the items you have commented on ended up on my plate and I should be able to do something about them. Cheers, Nick. P.S. 30 closures for 180 comments actually sounds like a reasonable SNR to me. Maybe my perspective is skewed by the fact that I'm not involved in most of them :) -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On Sun, Jul 18, 2010 at 5:22 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On Mon, Jul 19, 2010 at 4:43 AM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
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.
Please don't take it that way - Antoine and Alexander are just trying to help you make the most effective use of the time you spend contributing (which *is* appreciated!).
In my case, I don't spend much time trawling the tracker for issues, so I'm reliant on other people kicking import related issues in my direction by adding me to the nosy list or bringing them up here on python-dev. I think a couple of the items you have commented on ended up on my plate and I should be able to do something about them.
Cheers, Nick.
P.S. 30 closures for 180 comments actually sounds like a reasonable SNR to me. Maybe my perspective is skewed by the fact that I'm not involved in most of them :)
And I'm with Nick here. I don't have the time or bandwidth to trawl the tracker :( So you bumping things to/for me helps.

On 18/07/2010 22:24, Jesse Noller wrote:
On Sun, Jul 18, 2010 at 5:22 PM, Nick Coghlan<ncoghlan@gmail.com> wrote:
On Mon, Jul 19, 2010 at 4:43 AM, Mark Lawrence<breamoreboy@yahoo.co.uk> wrote:
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.
Please don't take it that way - Antoine and Alexander are just trying to help you make the most effective use of the time you spend contributing (which *is* appreciated!).
In my case, I don't spend much time trawling the tracker for issues, so I'm reliant on other people kicking import related issues in my direction by adding me to the nosy list or bringing them up here on python-dev. I think a couple of the items you have commented on ended up on my plate and I should be able to do something about them.
Cheers, Nick.
P.S. 30 closures for 180 comments actually sounds like a reasonable SNR to me. Maybe my perspective is skewed by the fact that I'm not involved in most of them :)
And I'm with Nick here. I don't have the time or bandwidth to trawl the tracker :( So you bumping things to/for me helps.
Nick, Jesse, Thank you for your kind comments, they're much appreciated. Now the fighter bombers dive in to finish of the last pockets of resistance. (from a Monty Python album in case you didn't know) What am I meant to do when as happened earlier today, I see an issue that was first raised two years ago, then a year later the OP has asked what if anything is happening? Leave it? That's a great advert for Python. How do I apply a patch that was raised *SEVEN* years ago to modern versions of Python? The issue is still open. I do my best to run the unit tests if they're available on an issue, but so often they're so old that it's all but impossible to apply them without a hell of a lot of manual work. If this had been done in the first place it wouldn't have been an issue. I believe that by now you get my drift. But to me the most infuriating thing on the bug tracker is when someone else has simply bumped the Python versions and that's it. No attempt at contacting the OP as to whether the issue is still applicable. No attempt to try the patches, all in all zilch. So I come along and attempt to backtrack years and get slagged off for it. Hell, I just wish I was fully healthy and had my MBCS/CEng status back, then I'd really feel capable of letting fly. Having worked on massive UK MOD projects (can't say much, Official Secrets Acts and all that stuff) and knowing a hell of a lot about change control, configuration management, call it what you like, quite frankly Python is years behind. But there I go again, can't rock the boat because someone might get upset, to hell with the poor sods putting in their patches years ago and being completely ignored. You all might have gathered that I'm very dispirited by the negative attitudes that I get from a relatively small minority of Python people. I might as well quit because it doesn't do my mental health a great deal of good. That minority will of course be very happy to see me go because they'll be able to sit back on their loathsome, spotty behinds picking blackheads and resort to the usual "we're far too busy to do anything" routine. You might understand that I don't completely agree with this. But to hell with it, I'm as usual feeling absolutely shattered so I'm going to bed, please don't try to close too many issues whilst I'm sleeping, I won't have anything to do tomorrow afternoon. Kindest regards. Mark Lawrence.

On Sun, Jul 18, 2010 at 7:06 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote: ..
What am I meant to do when as happened earlier today, I see an issue that was first raised two years ago, then a year later the OP has asked what if anything is happening? Leave it? That's a great advert for Python.
How do I apply a patch that was raised *SEVEN* years ago to modern versions of Python? The issue is still open. I do my best to run the unit tests if they're available on an issue, but so often they're so old that it's all but impossible to apply them without a hell of a lot of manual work. If this had been done in the first place it wouldn't have been an issue.
Don't get frustrated and don't give up. Python is valued for its stability and most patches are delayed for good reasons. Oftentimes the problem is simply nontrivial and the proposed patch is not obviously correct. In other cases the patch addresses a rare use case and is deemed not important enough to take priority over other things that are on developer's todo list. What to do with old patches? I would suggest the following steps: 1. Verify that the issue is still present in the latest releases. 2. Add a comment confirming that you were able to reproduce the bug and explain how. 3. Try to apply the patch. With a 7-year old patch your chances that it will apply cleanly are slim. Try both 2.x and 3.x branches. If patch contains tests, tests may apply but not code or the other way around. If you get any success, post your results. 4. If you find really egregious cases where you think that a valuable patch fell through the cracks, - bring it up here. By this time you probably have at least in your mind the list of issues that should have been closed long ago. Pick top three by value you think they would add and post here. I know first hand that posting a patch and see it linger until it does not apply anymore can be frustrating. One of the issues you flagged recently (http://bugs.python.org/issue4335) has a patch that I posted 1.5 years ago. It does not apply cleanly anymore and it would get a low priority on my list these days. Nevertheless, I appreciate the thorough approach that python developers take when it comes to accepting contributions or even committing their own changes. You may have noticed that developers with commit privileges often post their patches on the tracker first and get them reviewed before checking in. This is why python is such a high quality product. Once again, don't get frustrated. Your work is appreciated. There is room for all kinds of approaches to improving python and as long as you have time and desire to contribute, your contributions will make a difference.

On Mon, Jul 19, 2010 at 9:06 AM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
Hell, I just wish I was fully healthy and had my MBCS/CEng status back, then I'd really feel capable of letting fly. Having worked on massive UK MOD projects (can't say much, Official Secrets Acts and all that stuff) and knowing a hell of a lot about change control, configuration management, call it what you like, quite frankly Python is years behind. But there I go again, can't rock the boat because someone might get upset, to hell with the poor sods putting in their patches years ago and being completely ignored.
I have worked (and do work) on similar projects and in many ways Python is well ahead of what some large corporations do. In terms of test automation, baseline control, public auditing of the source repository, public communications, the very nature of open source development avoids a lot of the pitfalls private enterprise can fall into. We *have* to document and automate stuff, because you can't just yell over at Bob in the next cubicle to ask "hey, what do I need to install to get [fnord] to build?". We *know* that everything we commit is going to land in the email inbox of a large number of people, so we better give it a reasonable checkin message and include a meaningful comment explaining any apparently-stupid-but-actually-correct code. The fundamental constraint, though, is that the core developers aren't paid specifically to hack on Python. We may use it in our day jobs, and I think some of the folks may get a bit of time to spend on it during their work week, but making the new versions better isn't the primary task for any of us. Large corporations, on the other hand, have a lot more money to throw at things and can pay people to work on the boring stuff rather than relying purely on volunteers. If you get to a feature request, find that it doesn't apply cleanly anymore (or even come close), post a comment to say that. If nobody steps up to modernise the patch, but it isn't a fundamentally bad idea, then it's OK for the tracker issue to remain open indefinitely (e.g. one of mine you commented on recently I had deliberately left open for a long time because I hadn't made up my mind whether I agreed with it or not. There were some comments from earlier this year that I missed at the time, but reading them all now means that I'm inclined to accept the change for 3.2). For bug reports, the basic thing is to see if the issue can be reproduced on currently maintained versions. If it can, update the version applicability accordingly, if it can't, suggest closure as out of date. This isn't a company where the metrics mavens will see a growing count of low priority feature requests and issue reports and demand that they either be accepted or rejected and people will be taken from other tasks and given the responsibility to work through the list. Is it *good* that things are this way? No, not at all. But it isn't likely to change anytime soon, either. Cheers, Nick. P.S. Regarding the version bumps with no other comment: I believe there are some scripts kicking around to bump feature requests up to the new development version after a new release goes into maintenance-only mode. It may be good if any such scripts are updated to also add a comment to that effect, but I don't believe those scripts are centrally controlled anywhere. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On Mon, 19 Jul 2010 00:06:32 +0100, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
You all might have gathered that I'm very dispirited by the negative attitudes that I get from a relatively small minority of Python people. I might as well quit because it doesn't do my mental health a great deal of good. That minority will of course be very happy to see me go because they'll be able to sit back on their loathsome, spotty behinds picking blackheads and resort to the usual "we're far too busy to do anything" routine. You might understand that I don't completely agree with this.
Mark, please understand that (as far as I can tell) the "small minority of people" of whom you are speaking here, who have offered advice on how to make your triage work more helpful to the Python community, are some of the most *active* Python committers and community participants. I think the best thing for your mental health would be to see if you can just ignore things that seem negative, and see if there's any useful advice in what is said. And if you don't find the opinions useful, then you don't. The essence of community is cooperation, and cooperation can't happen without communication; and yes, some of it is going to sound negative (and some of it will even *be* negative...that's human nature, as your message demonstrates). Which I think you have done, since I've seen you put into practice some of the suggestions that were made. I regret that I haven't been able to follow your prolific work closely (in fact, I have had to stop following the bugs list, I now just watch the new bugs list...not just due to the volume, but because of my other commitments, but the volume certainly contributed, unfortunately[*]). I especially regret that because I was the one who gave you developer privs on the tracker, and so I have something of a responsibility to so. I'm relying on the positive feedback that you are getting here to assuage my guilt for not paying closer attention to your work, and also on the fact that I have seen the quality of your work improve over time from the bugs I have reviewed that you've commented on. -- R. David Murray www.bitdance.com [*] I think this may be a source of some of the discomfort you have sensed. I had been used to being able to keep up with the bugs list, but even before you started your work I was already thinking that that wasn't going to work for much longer...as Python becomes more popular, the number of bug reports increases, and as we add more committers and gather more people who are actively helping out, the message traffic increases. This is *good*: it means we are getting more done (well, at least if we can continue to add committers it does), but it also means that it is no longer possible for a part time volunteer to keep an overview of the bug/patch activity. The danger, of course, is that more things will slip through the cracks....but this is not, as you have observed, a new problem.

Am 18.07.2010 00:45, schrieb Mark Lawrence:
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.
That phrasing implies that there is purpose behind letting issues rot. Believe me that this is not the case.
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?
If no developer can invest the time necessary before, yes. Better not to apply a patch than to rush in something that might have a negative impact in the long run. For code such as Python's standard library, we have to think very carefully about everything that could affect compatibility or introduce new bugs or regressions. I don't want to say that all patches are seriously flawed, but for most patches I applied I had to make some changes before committing, and I needed time enough to think about them.
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.
And this is what is great about what you're doing, because many issues can be closed immediately, and some after minor work.
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.
Of course committers are different. I guess that most who complained did what I did, saying "I think you're doing a great job, but try to ...". Why not take the advice? Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

On 7/18/2010 7:42 PM, Georg Brandl wrote:
That phrasing implies that there is purpose behind letting issues rot. Believe me that this is not the case.
This seems like a good place to mention that doc issues have become a bright spot in the last few years, with a couple of days turnaround not unusual for an issue ready for commit review. This is one reason I have focused a bit on doc issues. It is rewarding. As I remember, a reason to switch from latex to sphinx/rst was so that more people could/would work on doc issues. That seems to have worked. And I do not think it bad is the docs catch up to the code by getting extra attention. -- Terry Jan Reedy

Am 19.07.2010 04:22, schrieb Terry Reedy:
On 7/18/2010 7:42 PM, Georg Brandl wrote:
That phrasing implies that there is purpose behind letting issues rot. Believe me that this is not the case.
This seems like a good place to mention that doc issues have become a bright spot in the last few years, with a couple of days turnaround not unusual for an issue ready for commit review. This is one reason I have focused a bit on doc issues. It is rewarding.
Because it's usually easier to review a doc patch -- you don't have to consider backwards compatibility implications :)
As I remember, a reason to switch from latex to sphinx/rst was so that more people could/would work on doc issues. That seems to have worked. And I do not think it bad is the docs catch up to the code by getting extra attention.
Yep, especially in Py3k where some changes were not really given enough docs love. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

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.
If you are then still interested in getting commit access, please send me your SSH key. Regards, Martin

On Sat, Jul 17, 2010 at 2:47 PM, Steve Holden wrote:
On 7/17/2010 7:33 AM, Antoine Pitrou wrote:
Hello,
On Sun, 11 Jul 2010 02:05:22 +0300 Tal Einat <taleinat@gmail.com> wrote:
I would like to propose removing IDLE from the standard library.
I have been using IDLE since 2002 and have been doing my best to help maintain and further develop IDLE since 2005.
I haven't seen any conclusive statement or action to this thread. Without being an IDLE user myself (for good reason), I think that if IDLE should stay, active contributors such as Tal should be given commit access and enough free rein to maintain and improve it.
Otherwise there's no reason to continue claiming that IDLE is important while discouraging such people's contributions. The current situation, where several core developers support IDLE's continued inclusion but none actually cares for the issues and patches in the tracker, is schizophrenic.
+1
There's no reason why Tal should be obstructed in his goal of making IDLE at least acceptable again. It's fairly obvious thaat there aren't any committers who have both the inclination /and/ the time to do this, so adding Tal (and other interested parties) as a developer makes a lot of sense.
I would certainly accept this as a first step. Although I now use IDLE much less than I have in previous years, I would be willing to put in some time towards fixing the major current issues and integrating the few polished enhancements. However, in the long run just allowing "heavy" contributors such as myself commit rights won't be enough. There's definitely a need for one or more active maintainers of IDLE who can take care of incoming bug reports and patches. We may hope that at least one serious contributor who is given commit rights will take up this position naturally, but perhaps a more active approach would be beneficial? I also think that there is a need for a guiding hand for IDLE, as Guido is for Python. It took a bit of time until I "got" the goals and principles of IDLE (e.g. easy to learn, minimal and obvious interface) by having KBK explain them in detail and explain the drawbacks of certain proposed changes. Having some kind of central authority is especially important in order to keep IDLE on track because the active development of IDLE is slow and done by various contributors -- there is currently no central group of active developers making such decisions. This doesn't have to be one person who also takes care of bugs, patches and testing, it could be someone who is just readily available via the idle-dev mailing list and keeps up with development of IDLE. Going along these lines of thought, I reach my original conclusion: IDLE is somewhat a project of its own. Perhaps considering IDLE a daughter-project of Python is appropriate, and continuing to develop it as part of the Python codebase could be reasonable, if more active maintainers can be found. I certainly support continuing to package it as part of the standard distribution.

There's no reason why Tal should be obstructed in his goal of making IDLE at least acceptable again. It's fairly obvious thaat there aren't any committers who have both the inclination /and/ the time to do this, so adding Tal (and other interested parties) as a developer makes a lot of sense.
I would certainly accept this as a first step. Although I now use IDLE much less than I have in previous years, I would be willing to put in some time towards fixing the major current issues and integrating the few polished enhancements.
If you want commit access, please send me your ssh key. Regards, Martin
participants (12)
-
"Martin v. Löwis"
-
Alexander Belopolsky
-
Antoine Pitrou
-
Georg Brandl
-
Jesse Noller
-
Mark Lawrence
-
Michael Foord
-
Nick Coghlan
-
R. David Murray
-
Steve Holden
-
Tal Einat
-
Terry Reedy