Re: [Python-Dev] Goodbye
Keywords are generally better than a restricted vocabulary for richness of content, but worse for finding the appropriate search term. You pays yer money and takes yer chance. I think you are unaware what a roundup keyword is, here. But without any smarts being applied to the problem it's always to know whether you are searching for the right keywords. The Python bug tracker has only 5 keywords at the moment, which all have a straight-forward meaning. Adding performance and resource usage would make it 7, which still would be manageable. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On Sat, Sep 25, 2010 at 1:12 AM, Antoine Pitrou solip...@pitrou.net wrote: But how should a performance improvement be filed? Bug? Feature request? Or should feature request be renamed improvement? It's a feature request (since we won't backport it unless there is a genuine performance problem being addressed as a bug fix). Whether that warrants changing the name, I don't know. I think most people won't intuitively file performance issues as feature requests, since it doesn't sound like a feature. Agreed. A third option for other improvement may also work (since that would also cover things like clarifying doc wording, fixing comments, adjusting code to be more readable/obviously correct, etc). But then why not keep a clear categorization of these other improvements? Because it's asking people to make a decision too early in the process. The clear categorisation as to what *kind* of bug/feature/improvement it is can be supplied later on by selecting the appropriate components and keywords. By the way, doc wording fixes and cosmetic code changes often get backported. :) Yep, hence why I think the basic bug, feature, other split may be a good way to go. It's a quick and easy decision most of the time (including a clear choice for I don't know if this is a bug or not), and makes a meaningful procedural distinction (bugs are usually backported, new features are not, and other changes may be backported depending on the details). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On 9/26/2010 7:43 AM, Nick Coghlan wrote: Yep, hence why I think the basic bug, feature, other split may be a good way to go. It's a quick and easy decision most of the time (including a clear choice for I don't know if this is a bug or not), and makes a meaningful procedural distinction (bugs are usually backported, new features are not, and other changes may be backported depending on the details). +1 on 3 categories. The categories other than the main two are used so seldom as to make the differentiation pretty useless. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
Éric Araujo writes: How about revamping the type/versions fields? Issue type () Feature request (blocked by moratorium: () yes () no) I think the information about blocked by moratorium is not something that users or devs will care about much. The users can be informed about the fact of the moratorium (There is currently a feature moratorium in effect. If this feature is determined to be a change in the language, it will not appear until Python 3.4 or later. Changes to the standard library functions are acceptable. If no progress is made on the issue in a reasonable time, you may request discussion on python-...@python.org.) in the reply page that confirms receipt of the issue. However, devs already know about the moratorium, and if there's a question of interpretation it will be discussed on python-dev. Users only care that their request is (not) being addressed; the moratorium is only one of many reasons why action is delayed. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On 9/24/2010 10:50 AM, Antoine Pitrou wrote: Le samedi 25 septembre 2010 à 00:42 +1000, Nick Coghlan a écrit : I have often used searches on performance or resource usage to find what was needing a review or a patch. I think it would be a mistake to remove those two categories. That purpose would be served just as well by keywords though (particularly since those attributes aren't mutually exclusive - resource usage problems will usually *cause* performance problems, and you may notice the latter first). Keywords are generally better than a restricted vocabulary for richness of content, but worse for finding the appropriate search term. You pays yer money and takes yer chance. Given that we could (if necessary) overlay some sort of Python-specific semantic category generation to searches if we needed to, I tend to favor the liberally tag with keywords approach. But without any smarts being applied to the problem it's always to know whether you are searching for the right keywords. A generic bug classification would also better suit documentation bugs. The simpler we can make the more common fields, while still providing the essential information, the better. But how should a performance improvement be filed? Bug? Feature request? Or should feature request be renamed improvement? Not all features would be improvements (and I'm thinking specifically here of 2.x's print f as an egregious design wart added for entirely pragmatic reasons). They could, however, be classified along with performance improvement requests as Enhancement requests. The big problem, I suspect, is that we don't give clear enough guidance to almost total noobs about how to fill in the issue tracker form. If you can't remember what your first month as a programmer was like then you probably aren't qualified to be writing int on-line help for the tracker. (The tracker does *have* on-line help, right?) regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
Am 23.09.2010 22:51, schrieb Éric Araujo: Le 23/09/2010 19:22, Terry Reedy a écrit : As of just now, if you were to wonder What (security) bugs are open for 2.5 and search on open 2.5 issues, you would get a list of 44 issues. It is only 44 instead of hundreds because of the work I and Mark have done in the last 4 months. It it 44 instead of perhaps 5 because Tarek and Eric insist on marking all disutils2 issues for all versions even though though these issues have nothing to do with maintenance releases. It is a real nuisance when trying to do tracker cleanup. Let’s fix this. Two days ago, I said this in http://bugs.python.org/issue2200#msg117003 : distutils2 has to work with 2.4-2.7 and (soon) 3.1-3.2, so Tarek told me to set all available versions for those bugs (2.5-py3k), even if I think “3rd party” is more appropriate and useful (since a distutils2 bug would not for example block a CPython 3.2 release). I’ve been following these rules since before GSoC, when I had less confidence and no will to conflict with Tarek on such a small thing wink. Now I argue that the versions field is not really useful for d2, since it lacks 2.4 which we support and chiefly because it does not actually help our workflow: We don’t have separate branches for backporting fixes, we apply patches and run tests for all supported versions before committing on a single branch. There is no use case of setting a version to remind that a port needs to be done. For bug purposes, I actually see distutils2 as a value for the versions field of distutils bugs. Thanks Eric, that sounds good. respect-my-non-ASCII-diversity-write-my-acute-accent-thanks’ly yours, Oops. My bad. 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
How about revamping the type/versions fields? Issue type () Feature request (blocked by moratorium: () yes () no) () Bug (found in: [] 2.7 [] 3.1 [] py3k) () Security bug (found in: [] 2.5 [] 2.6 [] 2.7 [] 3.1 [] py3k) I’m getting tired of explaining the meaning of the versions field again and again, let’s put this information directly under the eyes of the bug reporter. Regards ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On Fri, 24 Sep 2010 11:07:59 +0200 Éric Araujo mer...@netwok.org wrote: How about revamping the type/versions fields? Issue type () Feature request (blocked by moratorium: () yes () no) () Bug (found in: [] 2.7 [] 3.1 [] py3k) () Security bug (found in: [] 2.5 [] 2.6 [] 2.7 [] 3.1 [] py3k) I’m getting tired of explaining the meaning of the versions field again and again, let’s put this information directly under the eyes of the bug reporter. But we also have performance, crash, resource usage... Are we suggesting we devise a separate list box for each of these issue types? Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On Fri, Sep 24, 2010 at 10:26 PM, Antoine Pitrou solip...@pitrou.net wrote: On Fri, 24 Sep 2010 11:07:59 +0200 Éric Araujo mer...@netwok.org wrote: How about revamping the type/versions fields? Issue type () Feature request (blocked by moratorium: () yes () no) () Bug (found in: [] 2.7 [] 3.1 [] py3k) () Security bug (found in: [] 2.5 [] 2.6 [] 2.7 [] 3.1 [] py3k) I’m getting tired of explaining the meaning of the versions field again and again, let’s put this information directly under the eyes of the bug reporter. But we also have performance, crash, resource usage... Are we suggesting we devise a separate list box for each of these issue types? I must admit, I've never actually found much use for those additional options. If I'm flagging a bug I'll nearly always mark it behaviour, otherwise I'll mark the issue feature request. The characterisation of what *kind* of bug is it? is something that can usually be left until later in the process. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
But we also have performance, crash, resource usage... Are we suggesting we devise a separate list box for each of these issue types? I must admit, I've never actually found much use for those additional options. If I'm flagging a bug I'll nearly always mark it behaviour, otherwise I'll mark the issue feature request. The characterisation of what *kind* of bug is it? is something that can usually be left until later in the process. I have often used searches on performance or resource usage to find what was needing a review or a patch. I think it would be a mistake to remove those two categories. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On Sat, Sep 25, 2010 at 12:31 AM, Antoine Pitrou solip...@pitrou.net wrote: But we also have performance, crash, resource usage... Are we suggesting we devise a separate list box for each of these issue types? I must admit, I've never actually found much use for those additional options. If I'm flagging a bug I'll nearly always mark it behaviour, otherwise I'll mark the issue feature request. The characterisation of what *kind* of bug is it? is something that can usually be left until later in the process. I have often used searches on performance or resource usage to find what was needing a review or a patch. I think it would be a mistake to remove those two categories. That purpose would be served just as well by keywords though (particularly since those attributes aren't mutually exclusive - resource usage problems will usually *cause* performance problems, and you may notice the latter first). A generic bug classification would also better suit documentation bugs. The simpler we can make the more common fields, while still providing the essential information, the better. When someone like me is looking at a field pondering what to set it to for a comparatively simple issue report, what hope does someone submitted their first issue have? Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
Le samedi 25 septembre 2010 à 00:42 +1000, Nick Coghlan a écrit : I have often used searches on performance or resource usage to find what was needing a review or a patch. I think it would be a mistake to remove those two categories. That purpose would be served just as well by keywords though (particularly since those attributes aren't mutually exclusive - resource usage problems will usually *cause* performance problems, and you may notice the latter first). A generic bug classification would also better suit documentation bugs. The simpler we can make the more common fields, while still providing the essential information, the better. But how should a performance improvement be filed? Bug? Feature request? Or should feature request be renamed improvement? cheers Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On Sat, Sep 25, 2010 at 12:50 AM, Antoine Pitrou solip...@pitrou.net wrote: Le samedi 25 septembre 2010 à 00:42 +1000, Nick Coghlan a écrit : I have often used searches on performance or resource usage to find what was needing a review or a patch. I think it would be a mistake to remove those two categories. That purpose would be served just as well by keywords though (particularly since those attributes aren't mutually exclusive - resource usage problems will usually *cause* performance problems, and you may notice the latter first). A generic bug classification would also better suit documentation bugs. The simpler we can make the more common fields, while still providing the essential information, the better. But how should a performance improvement be filed? Bug? Feature request? Or should feature request be renamed improvement? It's a feature request (since we won't backport it unless there is a genuine performance problem being addressed as a bug fix). Whether that warrants changing the name, I don't know. A third option for other improvement may also work (since that would also cover things like clarifying doc wording, fixing comments, adjusting code to be more readable/obviously correct, etc). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
But how should a performance improvement be filed? Bug? Feature request? Or should feature request be renamed improvement? It's a feature request (since we won't backport it unless there is a genuine performance problem being addressed as a bug fix). Whether that warrants changing the name, I don't know. I think most people won't intuitively file performance issues as feature requests, since it doesn't sound like a feature. A third option for other improvement may also work (since that would also cover things like clarifying doc wording, fixing comments, adjusting code to be more readable/obviously correct, etc). But then why not keep a clear categorization of these other improvements? By the way, doc wording fixes and cosmetic code changes often get backported. :) cheers Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On 9/24/2010 1:41 AM, Stephen J. Turnbull wrote: Yes, and we'd all like more people to do more real work. But not everybody has the time or skills. I think this is a case where agreeing to disagree is the best we can do. There is also the matter of letting people start with something they feel condident with and grow into more complicated tasks. Specifically, Terry has made a strong case that a few minutes per issue *can* improve the tracker in ways that *are* noticable to some of the developers (and some of them have acknowledged that). It would be nice if the tracker trimmers[1] could assemble 60 of those into a few hours, and do some real work, but that's often just not possible (especially for people with minimal programming expertise as yet). Footnotes: [1] Trawlers take fish out of the ocean: not really the best metaphor. Gardening is a better metaphor. For instance, while 'gardening', I discovered 4! duplicate open issues about the bug created by the difflib.SequenceMatcher heuristic. I consolidated them into one, got intrigued, did some tests with 3.1, read difflib.py, ..., and now have a patch posted written with Eli Bendersky. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
Am 23.09.2010 04:35, schrieb Steven D'Aprano: On Thu, 23 Sep 2010 10:18:39 am Tim Peters wrote: Yikes - Mark has done terrific work in some very demanding areas, I'd hate to see him feel unwelcome. So that's my advice: find a way to smooth this over. You're welcome ;-) I'd like to second that. Mark has been pushy, annoying and demanding, although he has his bad points too *grins*. Seriously, Mark has brought a remarkable amount of energy to the tracker, for good and bad. The good shouldn't give him a Get Out Of Jail Free card forever, but in the absence of any knowledge of what lead to Mark's tracker privileges being revoked, I have no objections in principle to giving him a second chance if the devs decide that is acceptable and Mark is willing. (Not that my objections carry much weight.) I'd like to point out that only the Developer tracker privileges had been revoked at first, which meant that Mark could continue commenting and stirring up old issues, which is what made his work so valuable. He could not continue prematurely closing issues, which is what many devs objected to, and Raymond explained that to him in a private email (which I can only believe was polite and not at all offending). However, as a response to that, messages like this one started to be posted to several issues: http://bugs.python.org/msg117108 and since they were reposted even after being removed (unlinked) from the tracker item, the devs active on IRC at that moment could only suspect that this would continue for every issue that had Mark in its nosy list. That is a disruption that is not acceptable, and led to the removal of his User privilege as well, which I would say is wholly justified. Of course, this is *not* a ban! The privileges can be restored any time that Mark asks for it, but I would at least like to see an apology. Either way, I would like to publicly thank Mark for his efforts and wish him the best for the future. Same here. 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
deputed tracker authority/ies. Not everyone has the same idea about how to handle the various fields and processes. Who decides in cases of disagreement? We discussed this a while back and I don't think we really have a tracker BD. Brett and Martin come closest, but mostly we just sort of evolve a rough consensus. I think once Brett reduces that operating consensus to a written document things will be clearer. I personally think that the tracker fields and how they should be set is of minor importance. If there is a bug in Python, the most useful contribution is to submit a fix (or provide a rationale why this is not a bug). Asking every now and then is this still an issue, or setting the version number, doesn't really advance the issue. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
Am 23.09.2010 09:18, schrieb Martin v. Löwis: deputed tracker authority/ies. Not everyone has the same idea about how to handle the various fields and processes. Who decides in cases of disagreement? We discussed this a while back and I don't think we really have a tracker BD. Brett and Martin come closest, but mostly we just sort of evolve a rough consensus. I think once Brett reduces that operating consensus to a written document things will be clearer. I personally think that the tracker fields and how they should be set is of minor importance. If there is a bug in Python, the most useful contribution is to submit a fix (or provide a rationale why this is not a bug). Asking every now and then is this still an issue, or setting the version number, doesn't really advance the issue. It does however attract attention from developers who either weren't around when the original issue was submitted, or didn't feel competent enough to fix it then. It is also helpful to try reproducing the bug with a current version, in case the issue has been fixed already -- whether because of a duplicate bug report or by chance. 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On 23/09/2010 09:46, Georg Brandl wrote: Am 23.09.2010 09:18, schrieb Martin v. Löwis: I personally think that the tracker fields and how they should be set is of minor importance. If there is a bug in Python, the most useful contribution is to submit a fix (or provide a rationale why this is not a bug). Asking every now and then is this still an issue, or setting the version number, doesn't really advance the issue. It does however attract attention from developers who either weren't around when the original issue was submitted, or didn't feel competent enough to fix it then. It is also helpful to try reproducing the bug with a current version, in case the issue has been fixed already -- whether because of a duplicate bug report or by chance. I think my experience is that of several others. The work done by Mark and other tracker-trawlers has been useful: to dust off issues, attempt to assess their current validity, add suitable people to nosy lists, and where possible to try to reproduce or to encourage an OP to provide patches or other useful input. I've addressed, closed, or at least taken note of several issues in this way which I might not otherwise have done. The two less useful overspills of this generally useful activity have been: simple noise of the Is anyone interested in this? variety -- although even that might be useful, as Georg says, in highlighting older issues to newer developers; and the over-eager closure of calls on the basis of lack of response, and it seems to be an excess of this last which has brought the matter to a head. Let me ask a question which I don't think has been asked in this thread: are there guidelines for tracker-trawlers? I'm never sure where to look for this kind of thing myself. If there's nothing, I'm happy to pen a dos-and-donts (which I might do anyway, simply as a blog entry...) TJG ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
Let me ask a question which I don't think has been asked in this thread: are there guidelines for tracker-trawlers? I'm never sure where to look for this kind of thing myself. If there's nothing, I'm happy to pen a dos-and-donts (which I might do anyway, simply as a blog entry...) Can you please rephrase the question? What's a tracker-trawler? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On 23/09/2010 10:38, Martin v. Löwis wrote: Let me ask a question which I don't think has been asked in this thread: are there guidelines for tracker-trawlers? I'm never sure where to look for this kind of thing myself. If there's nothing, I'm happy to pen a dos-and-donts (which I might do anyway, simply as a blog entry...) Can you please rephrase the question? What's a tracker-trawler? My invented terminology for someone -- like Mark -- who invests time in going through issues in the tracker with a view to assessing them, prioritising them, de-duplicating, etc. As opposed to someone who's looking through issues with a view to finding things to fix within a particular area of competence. TJG ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On Thu, 23 Sep 2010 13:32:07 +0900 Stephen J. Turnbull step...@xemacs.org wrote: Triaging and closing bug reports are not the only functions of the tracker, and in fact they are subsidiary to actual bug-fixing work. +1. What we really need is people analyzing issues, posting patches or reviewing existing ones. Pushing for resolution of issues by threatening to close them isn't effective; it doesn't magically create more free time for us to deal with them. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On Wed, 22 Sep 2010 21:24:49 -0400 R. David Murray rdmur...@bitdance.com wrote: deputed tracker authority/ies. Not everyone has the same idea about how to handle the various fields and processes. Who decides in cases of disagreement? We discussed this a while back and I don't think we really have a tracker BD. Brett and Martin come closest, but mostly we just sort of evolve a rough consensus. If BD means Benevolent Dictator, then I certainly hope we don't need a tracker BD. I think the best until some written guideline exists is to watch how developers use the tracker today. There isn't much of a workflow apart from the initial version and priority setting. Everything is pretty much informal although we usually tend to follow the same steps. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
Am 23.09.2010 11:43, schrieb Tim Golden: On 23/09/2010 10:38, Martin v. Löwis wrote: Let me ask a question which I don't think has been asked in this thread: are there guidelines for tracker-trawlers? I'm never sure where to look for this kind of thing myself. If there's nothing, I'm happy to pen a dos-and-donts (which I might do anyway, simply as a blog entry...) Can you please rephrase the question? What's a tracker-trawler? My invented terminology for someone -- like Mark -- who invests time in going through issues in the tracker with a view to assessing them, prioritising them, de-duplicating, etc. As opposed to someone who's looking through issues with a view to finding things to fix within a particular area of competence. Ah. I think this goes to the core of the dispute: My recommendation is not to trawl at all. Instead, if you *really* want to contribute to Python, pick some area that you think needs most attention, and go through the tracker, and acquire competence in that area. The question is how much time you want to spend per issue. If it's only a few minutes per issue, I question whether this is a useful activity. If the issue has been long-standing, most likely, a few minutes will not be enough. There may, occasionally, be an issue that has been forgotten about, but overall, I'd expect that that the amount of wasted time becomes considerable - you can spend hours and hours looking through issues just to find out that they are all really tricky and would require a lot of expertise to resolve, which you then are not willing to acquire. Also, for me, as somebody on the nosy list, this activity doesn't help: *I* would have to spend much more time than I have at hands. So any is this still valid? message gets deleted immediately, especially if there are ten of them in my inbox. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On 23/09/2010 10:59, Antoine Pitrou wrote: On Thu, 23 Sep 2010 13:32:07 +0900 Stephen J. Turnbullstep...@xemacs.org wrote: Triaging and closing bug reports are not the only functions of the tracker, and in fact they are subsidiary to actual bug-fixing work. +1. What we really need is people analyzing issues, posting patches or reviewing existing ones. Pushing for resolution of issues by threatening to close them isn't effective; it doesn't magically create more free time for us to deal with them. Well, useful things that can still be done in triaging on old issues: checking that a bug still exists checking that a patch still applies and that tests still pass pointing out if a patch lacks tests seeing if the issue is duplicated elsewhere If it is a *feature request* (as opposed to a bug report - and I appreciate that the difference is often unclear) and the original poster has 'lost interest' then closing the issue may be a reasonable response. As others have mentioned, bumping old issues can bring it to the attention of developers monitoring on IRC or the bug mailing list who may not have seen the original report. On all issues, new or old, additional potentially useful things to do: make sure the issue is assigned to the right person if appropriate add relevant keywords to make it easier to find in searches ensure other fields in the tracker are filled in correctly closing the issue if it is invalid or expired (for example it only applies to an out of maintenance version of Python) Some developers (Martin and Antoine at least) have complained about the 'noise' of receiving extra emails on issues they are nosy on. Several developers have stated that they have found it useful (myself, Guido and Tim Golden at least) - so there is certainly no consensus that this work is pointless. All the best, Michael Foord Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
make sure the issue is assigned to the right person if appropriate -1. We typically don't assign issues to others. add relevant keywords to make it easier to find in searches -0. Going through old issues just to make sure the keywords are right seems wasteful. ensure other fields in the tracker are filled in correctly Likewise. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On 23/09/2010 13:11, Martin v. Löwis wrote: make sure the issue is assigned to the right person if appropriate -1. We typically don't assign issues to others. Some people have requested to be assigned to issues. (Myself for unittest, Ronald for Mac OS X issues etc.) add relevant keywords to make it easier to find in searches -0. Going through old issues just to make sure the keywords are right seems wasteful. Hard as it may be to believe, we do have (and are trying to cultivate) people who want to contribute to Python and start by searching for issues at the bug tracker. All the best, Michael ensure other fields in the tracker are filled in correctly Likewise. Regards, Martin -- 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
add relevant keywords to make it easier to find in searches -0. Going through old issues just to make sure the keywords are right seems wasteful. Hard as it may be to believe, we do have (and are trying to cultivate) people who want to contribute to Python and start by searching for issues at the bug tracker. Sure. However, on any specific search, many issues come up already. So people searching for stuff to do will easily find tasks already. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On 23/09/2010 13:28, Martin v. Löwis wrote: add relevant keywords to make it easier to find in searches -0. Going through old issues just to make sure the keywords are right seems wasteful. Hard as it may be to believe, we do have (and are trying to cultivate) people who want to contribute to Python and start by searching for issues at the bug tracker. Sure. However, on any specific search, many issues come up already. So people searching for stuff to do will easily find tasks already. Seems to me that the distinction to be made here is between activity which might, to some, appear a waste of time (eg setting flags and versions on existing calls) but which at worst provides no benefit and in fact might help someone narrow down a search more easily; and activity which is simply flatus vocis and which actually distracts or irritates. Individuals' thresholds clearly vary. TJG ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On 9/23/2010 3:18 AM, Martin v. Löwis wrote: I personally think that the tracker fields and how they should be set is of minor importance. As of just now, if you were to wonder What (security) bugs are open for 2.5 and search on open 2.5 issues, you would get a list of 44 issues. It is only 44 instead of hundreds because of the work I and Mark have done in the last 4 months. It it 44 instead of perhaps 5 because Tarek and Eric insist on marking all disutils2 issues for all versions even though though these issues have nothing to do with maintenance releases. It is a real nuisance when trying to do tracker cleanup. Trying to do searches in databases with inaccurate key data is a pain. If there is a bug in Python, the most useful contribution is to submit a fix (or provide a rationale why this is not a bug). Agreed,at least abstractly, with applying a fix a close second. That does not mean that other activities are useless. However, there are currently 1034 issues with the patch keyword set and perhaps others with pacthes. So I think one can legitimately ask whether adding more *new* patches, to possibly sit unreviewed for years, is the most useful contribution at the moment. In any case, asking whether a patch submitted for 2.5 (and now 2.6) is relevant to future maintenance releases amounts to suggesting that is may not be a bug for current purposes. Certainly, anyone fixing a bug for 2.7 should also know whether or not it is also a 3.x bug. Asking every now and then is this still an issue, or setting the version number, doesn't really advance the issue. Numerous issues have been advanced by the questions I and Mark have asked. Some were legitimately closed as out of date (the bug reported for 2.4/5/6 had already been fixed). Others were closed as fixed when someone committed something. The fact that Mark got over-zealous in closing issues too soon does not negate this. Some of our questions were more specific, and asking questions was not the only things we did. I tested some old reports against 3.1 and I believe Mark also did some testing himself. Setting Versions properly helps anyone searching for issues relevant to a particular version. If having a field set properly does not matter, then is should not be there. Are you suggesting that Versions be deleted? -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On 9/23/2010 8:11 AM, Martin v. Löwis wrote: make sure the issue is assigned to the right person if appropriate -1. We typically don't assign issues to others. What I and Mark (that I know of) did in that respect was to assign doc issues, including old issues reclassified as doc issues, to d...@python. add relevant keywords to make it easier to find in searches -0. Going through old issues just to make sure the keywords are right seems wasteful. ensure other fields in the tracker are filled in correctly Likewise. I am guessing that you have never done professional database management. And I suspect you would not be temperamentally suited to such. To repeat what I said in another post, if it does not matter how a field is set, it should not be there. You seem really antagonistic to, or at least dismissive of, people who contribute in ways other than how you do. That strikes me as unhelpful. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
Speaking as a frequent contributor of bug reports and an occasional contributor of patches, I must say that I feel like status quo of the tracker before Mark's work was discouraging. If there is a vast collection of abandoned tickets, it gives me the strong impression that my attempted contributions are likely to end up in that pile. The messages I got from the tracker due to Mark's work saying things like This ticket is closed due to inactivity. or Would you be interested in refreshing this patch? started to get me interested in contributing again. Also, I would like to point out that, not having read the other traffic that this thread alludes to, either from earlier mailing list threads or from IRC, I don't really understand what exactly Mark did wrong. The complaints about his behavior on this thread seem to be a little... non-specific. Did he continue to close tickets after he was asked not to do so? I didn't see any quotes or timestamps showing what happened or when. Regards, Zooko ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On 9/23/2010 1:44 PM, Terry Reedy wrote: On 9/23/2010 8:11 AM, Martin v. Löwis wrote: make sure the issue is assigned to the right person if appropriate -1. We typically don't assign issues to others. What I and Mark (that I know of) did in that respect was to assign doc issues, including old issues reclassified as doc issues, to d...@python. add relevant keywords to make it easier to find in searches -0. Going through old issues just to make sure the keywords are right seems wasteful. ensure other fields in the tracker are filled in correctly Likewise. I am guessing that you have never done professional database management. And I suspect you would not be temperamentally suited to such. To repeat what I said in another post, if it does not matter how a field is set, it should not be there. You seem really antagonistic to, or at least dismissive of, people who contribute in ways other than how you do. That strikes me as unhelpful. And before this descends into a general discussion of various people's approach to collaboration, let me remind us all that it does indeed take all sorts to make a world. From what I have seen on this list, nobody has suggested that Mark's work was *all* unhelpful. The fact that he can be difficult to work with doesn't remove the value of much of the work he was doing, and I am happy to note that there doesn't seem to be any blanket verdict that Mark should never have tracker privileges again. Mark courageously admitted on this list to having personal problems to overcome. That made me, at least, more sympathetic to his case, and more tolerant of his foibles and style of communication. I appreciate that a disruptive team member might eventually have to be isolated for the good of the team, but I am sorry to note that it came to that in Mark's case, and I hope that eventually he can return to the fold somehow. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On Thu, 23 Sep 2010 11:50:26 -0600, Zooko O'Whielacronx zo...@zooko.com wrote: Also, I would like to point out that, not having read the other traffic that this thread alludes to, either from earlier mailing list threads or from IRC, I don't really understand what exactly Mark did wrong. The complaints about his behavior on this thread seem to be a little... non-specific. Did he continue to close tickets after he was asked not to do so? I didn't see any quotes or timestamps showing what happened or when. Yes. It was necessary for the devs to monitor his work and re-open tickets he closed inappropriately. We always explained why the closure was inappropriate. The number of tickets closed inappropriately was growing rather than shrinking. It was this latter fact that, I believe, led to what happened. I think this could have been handled better, but thankfully this is not a situation we often find ourselves in, so we don't have much practice at dealing with such. Good ideas for procedures have been aired here as a result, so if the next incident is not too far in the future hopefully we'll handle the next one more smoothly. (But you'll excuse me for hoping it is so far in the future that we forget :) Again, there was nothing preventing Mark from continuing to comment on issues, test things, ask questions, and even suggest that issues be closed. However, his inappropriate response to losing triage privileges was causing significant problems on the tracker, and so we were forced to disable his account. This disabling does not need to be permanent. -- R. David Murray www.bitdance.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
Am 23.09.2010 19:22, schrieb Terry Reedy: Asking every now and then is this still an issue, or setting the version number, doesn't really advance the issue. Numerous issues have been advanced by the questions I and Mark have asked. Some were legitimately closed as out of date (the bug reported for 2.4/5/6 had already been fixed). Others were closed as fixed when someone committed something. The fact that Mark got over-zealous in closing issues too soon does not negate this. Some of our questions were more specific, and asking questions was not the only things we did. I tested some old reports against 3.1 and I believe Mark also did some testing himself. Setting Versions properly helps anyone searching for issues relevant to a particular version. If having a field set properly does not matter, then is should not be there. Are you suggesting that Versions be deleted? ISTM that the versions field is not very useful if the other fields are filled accurately. For example, feature requests almost always only belong to the current trunk. Yes, for features that fall under the moratorium, the versions field would be different; however, we already have an after moratorium keyword that signifies this. Other than this, we currently don't assign feature requests to specific milestones, and I don't ever see us doing that. Bug reports by nature almost always belong to all branches in maintenance; if the bug in question is a regression, the reporter will usually report that; if it is in a new feature, a) the reporter might not know that anyway, but b) the committer fixing it will without looking at versions. Security bugs are the last category, but they are also better served with a security keyword than with specific versions settings. The only use I see in the field is for the reporter to indicate which version he used when finding a bug; however this is next to useless since you have to reproduce it anyway, and ask for more detail when you can't. 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
Le 23/09/2010 19:22, Terry Reedy a écrit : As of just now, if you were to wonder What (security) bugs are open for 2.5 and search on open 2.5 issues, you would get a list of 44 issues. It is only 44 instead of hundreds because of the work I and Mark have done in the last 4 months. It it 44 instead of perhaps 5 because Tarek and Eric insist on marking all disutils2 issues for all versions even though though these issues have nothing to do with maintenance releases. It is a real nuisance when trying to do tracker cleanup. Let’s fix this. Two days ago, I said this in http://bugs.python.org/issue2200#msg117003 : distutils2 has to work with 2.4-2.7 and (soon) 3.1-3.2, so Tarek told me to set all available versions for those bugs (2.5-py3k), even if I think “3rd party” is more appropriate and useful (since a distutils2 bug would not for example block a CPython 3.2 release). I’ve been following these rules since before GSoC, when I had less confidence and no will to conflict with Tarek on such a small thing wink. Now I argue that the versions field is not really useful for d2, since it lacks 2.4 which we support and chiefly because it does not actually help our workflow: We don’t have separate branches for backporting fixes, we apply patches and run tests for all supported versions before committing on a single branch. There is no use case of setting a version to remind that a port needs to be done. For bug purposes, I actually see distutils2 as a value for the versions field of distutils bugs. In short, setting versions other than “3rd party” for distutils2 bugs does not help distutils2 and raises unhelpful results for people querying the status of CPython releases. +1 on changing that. respect-my-non-ASCII-diversity-write-my-acute-accent-thanks’ly yours, Éric ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
Asking every now and then is this still an issue, or setting the version number, doesn't really advance the issue. Setting Versions properly helps anyone searching for issues relevant to a particular version. If having a field set properly does not matter, then is should not be there. Are you suggesting that Versions be deleted? I didn't say the field does not matter. I said adjusting it doesn't advance the issue. Anybody *really* working on the issue might choose to update it, or might choose to leave it incorrect when the issue is going to be closed, anyway. I do believe that much of the information on closed issues is irrelevant - yet I would oppose to deleting them entirely from the database. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On 9/23/2010 3:50 PM, Georg Brandl wrote: ISTM that the versions field is not very useful if the other fields are filled accurately. For example, feature requests almost always only belong to the current trunk. Yes, for features that fall under the moratorium, the versions field would be different; however, we already have an after moratorium keyword that signifies this. Other than this, we currently don't assign feature requests to specific milestones, and I don't ever see us doing that. Bug reports by nature almost always belong to all branches in maintenance; For various reasons, there bugs that are 2.x or 3.x specific. Those that are not may require sufficiently different fixes that a fix is applied for one branch while the issue is left open for the other. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On Fri, Sep 24, 2010 at 5:50 AM, Georg Brandl g.bra...@gmx.net wrote: Setting Versions properly helps anyone searching for issues relevant to a particular version. If having a field set properly does not matter, then is should not be there. Are you suggesting that Versions be deleted? ISTM that the versions field is not very useful if the other fields are filled accurately. It's useful for bug reports to flag affected versions. We should probably just *not set it* for feature requests, though. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On Fri, Sep 24, 2010 at 3:44 AM, Terry Reedy tjre...@udel.edu wrote: On 9/23/2010 8:11 AM, Martin v. Löwis wrote: make sure the issue is assigned to the right person if appropriate -1. We typically don't assign issues to others. What I and Mark (that I know of) did in that respect was to assign doc issues, including old issues reclassified as doc issues, to d...@python. The other thing is that the maintainers file is there specifically to help the triage team decide when a direct assignment is appropriate, or just adding people to the nosy list. Since I don't follow the bugs list myself, the latter is *very* helpful to me. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On 9/23/2010 6:17 PM, Nick Coghlan wrote: On Fri, Sep 24, 2010 at 5:50 AM, Georg Brandlg.bra...@gmx.net wrote: Setting Versions properly helps anyone searching for issues relevant to a particular version. If having a field set properly does not matter, then is should not be there. Are you suggesting that Versions be deleted? ISTM that the versions field is not very useful if the other fields are filled accurately. It's useful for bug reports to flag affected versions. We should probably just *not set it* for feature requests, though. Now that 2.7 is out, so that feature requests can only be for a future 3.x, I would actually like the tracker to restrict the allowed values for non-doc feature requests either to 3.2/3.3 or to Not Applicable or whatever. It is a nuisance that people can still file such for 2.7, for instance. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
So if there turns out to be a major security hole or sever bug in 2.7, then it shouldn't be filed against 2.7? and fixed in a 2.7.x sort of branch? In that case, would you just suggest everyone using 2.7 to jump to 3.x? As long as a 2.x version is supported, filing bugs, branching and even releasing critical updates is, although rare, a fact of life. On Thu, 23 Sep 2010 19:06:29 -0400, Terry Reedy tjre...@udel.edu wrote: On 9/23/2010 6:17 PM, Nick Coghlan wrote: On Fri, Sep 24, 2010 at 5:50 AM, Georg Brandlg.bra...@gmx.net wrote: Setting Versions properly helps anyone searching for issues relevant to a particular version. If having a field set properly does not matter, then is should not be there. Are you suggesting that Versions be deleted? ISTM that the versions field is not very useful if the other fields are filled accurately. It's useful for bug reports to flag affected versions. We should probably just *not set it* for feature requests, though. Now that 2.7 is out, so that feature requests can only be for a future 3.x, I would actually like the tracker to restrict the allowed values for non-doc feature requests either to 3.2/3.3 or to Not Applicable or whatever. It is a nuisance that people can still file such for 2.7, for instance. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On 9/23/2010 7:12 PM, dar...@ontrenet.com wrote: So if there turns out to be a major security hole or sever bug in 2.7, then it shouldn't be filed against 2.7? and fixed in a 2.7.x sort of branch? In that case, would you just suggest everyone using 2.7 to jump to 3.x? As long as a 2.x version is supported, filing bugs, branching and even releasing critical updates is, although rare, a fact of life. I am not sure who or what you are responding to. The below is based on the fact the 2.7 is now closed to *new features* and will be as long as the CPython pydev group maintains it. In another post I said that the Versions field is needed for *bugs* as long as we are maintaining 2.7, which will be for several years, because there are and will continue to be 2.7 and 3.x specific bugs. If you want *new features*, then yes, you need to jump to 3.x. Otherwise you can relax, and perhaps contribute to 2.7 bug fixes if you want. Now that 2.7 is out, so that feature requests can only be for a future 3.x, I would actually like the tracker to restrict the allowed values for non-doc feature requests either to 3.2/3.3 or to Not Applicable or whatever. It is a nuisance that people can still file such for 2.7, for instance. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
Martin v. Löwis writes: I didn't say the field does not matter. I said adjusting it doesn't advance the issue. Anybody *really* working on the issue might choose to update it, or might choose to leave it incorrect when the issue is going to be closed, anyway. Yes, and we'd all like more people to do more real work. But not everybody has the time or skills. I think this is a case where agreeing to disagree is the best we can do. Specifically, Terry has made a strong case that a few minutes per issue *can* improve the tracker in ways that *are* noticable to some of the developers (and some of them have acknowledged that). It would be nice if the tracker trimmers[1] could assemble 60 of those into a few hours, and do some real work, but that's often just not possible (especially for people with minimal programming expertise as yet). Footnotes: [1] Trawlers take fish out of the ocean: not really the best metaphor. Gardening is a better metaphor. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On Tue, 21 Sep 2010 20:16:52 -0400 Jack Diederich jackd...@gmail.com wrote: On Tue, Sep 21, 2010 at 7:58 PM, Mark Lawrence breamore...@yahoo.co.uk wrote: I'm rather sad to have been sacked, but such is life. I won't be doing any more work on the bug tracker for obvious reasons, but hope that you who have managed to keep your voluntary jobs manage to keep Python going. Umm, what? You mean http://bugs.python.org/issue2180 ? Mark, please stop closing these based on age. The needs to be a determination whether this is a valid bug. If so, then a patch is needed. If not, it can be closed. Am I missing something? Simply, situations like the above (Mark closing a bug just because nobody would answer his message on a short delay) have happened multiple times - despite people opposing, obviously -, and we decided that it was better to remove his tracker privileges since his contribution has not really been productive for us. There was a whole python-dev thread some time (weeks? months?) ago where several of us already tried to suggest more fruitful ways of contributing, suggestions which weren't received very welcomingly AFAIR. Now I understand that opinions over this may vary and involve multiple factors, but I would suggest that at least a bit of mentoring is needed if we want to give privileges early on. (and the amount of mentoring needed can vary wildly from one person to another) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On Wed, Sep 22, 2010 at 8:47 PM, Antoine Pitrou solip...@pitrou.net wrote: Simply, situations like the above (Mark closing a bug just because nobody would answer his message on a short delay) have happened multiple times - despite people opposing, obviously -, and we decided that it was better to remove his tracker privileges since his contribution has not really been productive for us. There was a whole python-dev thread some time (weeks? months?) ago where several of us already tried to suggest more fruitful ways of contributing, suggestions which weren't received very welcomingly AFAIR. Now I understand that opinions over this may vary and involve multiple factors, but I would suggest that at least a bit of mentoring is needed if we want to give privileges early on. (and the amount of mentoring needed can vary wildly from one person to another) I still prefer the trust but monitor approach over excessively high barriers to entry, but we do need to recognise that one consequence of that approach is that we *will* get into situations where we need to tell people thank you for your contributions, but we think, on balance, we will be better off if you don't contribute in this way any more. Mark *did* do quite a bit of good in his time with tracker privileges. A number of lingering issues that would have otherwise continued lingering did indeed get closed. That work is still appreciated, even if it was ultimately deemed by the other tracker admins not to be sufficient to balance out the hassles created by his aggressive stance towards closing older issues (which, while unloved, are not automatically invalid). If this had happened *without* the prior discussion regarding more appropriate handling of tracker issues, then I would have an issue with it. However, given that the first reaction was to provide additional mentoring, with revocation of privileges only happening when the problems continued, that seems to me like the way this process is *meant* to work. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On 9/21/2010 7:58 PM, Mark Lawrence wrote: I'm rather sad to have been sacked, but such is life. I won't be doing any more work on the bug tracker for obvious reasons, but hope that you who have managed to keep your voluntary jobs manage to keep Python going. Kindest regards. Mark Lawrence. Mark: Whatever the situation vis a vis the bug tracker, thank you for caring enough about Python to put in the time that you have. If you didn't care you would not have done all that hard work, and I hope you can find other ways to contribute further to Python's success. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On Wed, Sep 22, 2010 at 4:07 AM, Nick Coghlan ncogh...@gmail.com wrote: On Wed, Sep 22, 2010 at 8:47 PM, Antoine Pitrou solip...@pitrou.net wrote: Simply, situations like the above (Mark closing a bug just because nobody would answer his message on a short delay) have happened multiple times - despite people opposing, obviously -, and we decided that it was better to remove his tracker privileges since his contribution has not really been productive for us. There was a whole python-dev thread some time (weeks? months?) ago where I think it was the thread No response to posts started (by Mark) on July 31. several of us already tried to suggest more fruitful ways of contributing, suggestions which weren't received very welcomingly AFAIR. Yup. In that thread (and others) I see lots of evidence where Mark responded very negatively (from I disagree entirely to I find this response quite pathetic) when people explained how we treat the tracker, and stuck to his guns no matter how many people tried to explain that he should stop. His attitude can be summarized by his Fly back at me if you like. I don't care about me. I don't care about you. I do care about Python. Which to me sounds defiant and passive-aggressive. I don't want to go into analyzing, but I expect that Mark has issues that are beyond what this community can deal with. Now I understand that opinions over this may vary and involve multiple factors, but I would suggest that at least a bit of mentoring is needed if we want to give privileges early on. (and the amount of mentoring needed can vary wildly from one person to another) I still prefer the trust but monitor approach over excessively high barriers to entry, but we do need to recognise that one consequence of that approach is that we *will* get into situations where we need to tell people thank you for your contributions, but we think, on balance, we will be better off if you don't contribute in this way any more. Mark *did* do quite a bit of good in his time with tracker privileges. Right, that was my impression from the issues he touched on which I happened to be subscribed. A number of lingering issues that would have otherwise continued lingering did indeed get closed. That work is still appreciated, even if it was ultimately deemed by the other tracker admins not to be sufficient to balance out the hassles created by his aggressive stance towards closing older issues (which, while unloved, are not automatically invalid). How and how often was Mark reminded about this? If this had happened *without* the prior discussion regarding more appropriate handling of tracker issues, then I would have an issue with it. However, given that the first reaction was to provide additional mentoring, with revocation of privileges only happening when the problems continued, that seems to me like the way this process is *meant* to work. Where was the decision to revoke privileges discussed? Not on any mailing list that I am subscribed to. Was Mark given an ultimatum? Given that this came out rather unfortunately (even if the end result is the best that could have happened) I would recommend that in the future more attention is paid to documenting publicly that someone's being booted out was inevitable, by an exchange of messages on python-dev (or python-committers if we want to limit distribution). And no, I don't think that IRC (where I suspect this happened) is sufficient. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
If you guys continue to make a public jury of this, no one else will want to step into that role On Wed, Sep 22, 2010 at 4:07 AM, Nick Coghlan ncogh...@gmail.com wrote: On Wed, Sep 22, 2010 at 8:47 PM, Antoine Pitrou solip...@pitrou.net wrote: Simply, situations like the above (Mark closing a bug just because nobody would answer his message on a short delay) have happened multiple times - despite people opposing, obviously -, and we decided that it was better to remove his tracker privileges since his contribution has not really been productive for us. There was a whole python-dev thread some time (weeks? months?) ago where I think it was the thread No response to posts started (by Mark) on July 31. several of us already tried to suggest more fruitful ways of contributing, suggestions which weren't received very welcomingly AFAIR. Yup. In that thread (and others) I see lots of evidence where Mark responded very negatively (from I disagree entirely to I find this response quite pathetic) when people explained how we treat the tracker, and stuck to his guns no matter how many people tried to explain that he should stop. His attitude can be summarized by his Fly back at me if you like. I don't care about me. I don't care about you. I do care about Python. Which to me sounds defiant and passive-aggressive. I don't want to go into analyzing, but I expect that Mark has issues that are beyond what this community can deal with. Now I understand that opinions over this may vary and involve multiple factors, but I would suggest that at least a bit of mentoring is needed if we want to give privileges early on. (and the amount of mentoring needed can vary wildly from one person to another) I still prefer the trust but monitor approach over excessively high barriers to entry, but we do need to recognise that one consequence of that approach is that we *will* get into situations where we need to tell people thank you for your contributions, but we think, on balance, we will be better off if you don't contribute in this way any more. Mark *did* do quite a bit of good in his time with tracker privileges. Right, that was my impression from the issues he touched on which I happened to be subscribed. A number of lingering issues that would have otherwise continued lingering did indeed get closed. That work is still appreciated, even if it was ultimately deemed by the other tracker admins not to be sufficient to balance out the hassles created by his aggressive stance towards closing older issues (which, while unloved, are not automatically invalid). How and how often was Mark reminded about this? If this had happened *without* the prior discussion regarding more appropriate handling of tracker issues, then I would have an issue with it. However, given that the first reaction was to provide additional mentoring, with revocation of privileges only happening when the problems continued, that seems to me like the way this process is *meant* to work. Where was the decision to revoke privileges discussed? Not on any mailing list that I am subscribed to. Was Mark given an ultimatum? Given that this came out rather unfortunately (even if the end result is the best that could have happened) I would recommend that in the future more attention is paid to documenting publicly that someone's being booted out was inevitable, by an exchange of messages on python-dev (or python-committers if we want to limit distribution). And no, I don't think that IRC (where I suspect this happened) is sufficient. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/darren%40ontrenet.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
2010/9/22 Guido van Rossum gu...@python.org: On Wed, Sep 22, 2010 at 4:07 AM, Nick Coghlan ncogh...@gmail.com wrote: A number of lingering issues that would have otherwise continued lingering did indeed get closed. That work is still appreciated, even if it was ultimately deemed by the other tracker admins not to be sufficient to balance out the hassles created by his aggressive stance towards closing older issues (which, while unloved, are not automatically invalid). How and how often was Mark reminded about this? I believe that mailing list thread was the main thrust. However, many issues which he closed were reopened with a message saying why they shouldn't be closed. If this had happened *without* the prior discussion regarding more appropriate handling of tracker issues, then I would have an issue with it. However, given that the first reaction was to provide additional mentoring, with revocation of privileges only happening when the problems continued, that seems to me like the way this process is *meant* to work. Where was the decision to revoke privileges discussed? Not on any mailing list that I am subscribed to. Was Mark given an ultimatum? Indeed, it was on IRC. Given that this came out rather unfortunately (even if the end result is the best that could have happened) I would recommend that in the future more attention is paid to documenting publicly that someone's being booted out was inevitable, by an exchange of messages on python-dev (or python-committers if we want to limit distribution). And no, I don't think that IRC (where I suspect this happened) is sufficient. We'll note that for the future. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On 22/09/2010 15:33, dar...@ontrenet.com wrote: If you guys continue to make a public jury of this, no one else will want to step into that role One of the perhaps-downsides of projects with an open community and open development processes is that any dirty-laundry there might be tends to get washed in public. Difficult decisions will always be accompanied by a measure of soul-searching and disagreement. I guess this is what you mean by public jury. I think reaching decisions like this in private, without public discussion, would be worse (decisions could only be made by a 'secret cabal' with much less accountability and opportunity to improve). I don't think this kind of process can ever be easy (unless we eliminate the involvement of humans in Python development altogether), but we do have a process. Particularly bearing in mind the comments of Guido on the topic we can further improve the process. I too found Mark's contributions to issues I'm involved in helpful, but I understand the decision entirely. We all need to be able to work together and despite best efforts that just wasn't working out. I also wish Mark the best for the future and hope that he is still able to find some way to contribute to Python. All the best, Michael Foord On Wed, Sep 22, 2010 at 4:07 AM, Nick Coghlanncogh...@gmail.com wrote: On Wed, Sep 22, 2010 at 8:47 PM, Antoine Pitrousolip...@pitrou.net wrote: Simply, situations like the above (Mark closing a bug just because nobody would answer his message on a short delay) have happened multiple times - despite people opposing, obviously -, and we decided that it was better to remove his tracker privileges since his contribution has not really been productive for us. There was a whole python-dev thread some time (weeks? months?) ago where I think it was the thread No response to posts started (by Mark) on July 31. several of us already tried to suggest more fruitful ways of contributing, suggestions which weren't received very welcomingly AFAIR. Yup. In that thread (and others) I see lots of evidence where Mark responded very negatively (from I disagree entirely to I find this response quite pathetic) when people explained how we treat the tracker, and stuck to his guns no matter how many people tried to explain that he should stop. His attitude can be summarized by his Fly back at me if you like. I don't care about me. I don't care about you. I do care about Python. Which to me sounds defiant and passive-aggressive. I don't want to go into analyzing, but I expect that Mark has issues that are beyond what this community can deal with. Now I understand that opinions over this may vary and involve multiple factors, but I would suggest that at least a bit of mentoring is needed if we want to give privileges early on. (and the amount of mentoring needed can vary wildly from one person to another) I still prefer the trust but monitor approach over excessively high barriers to entry, but we do need to recognise that one consequence of that approach is that we *will* get into situations where we need to tell people thank you for your contributions, but we think, on balance, we will be better off if you don't contribute in this way any more. Mark *did* do quite a bit of good in his time with tracker privileges. Right, that was my impression from the issues he touched on which I happened to be subscribed. A number of lingering issues that would have otherwise continued lingering did indeed get closed. That work is still appreciated, even if it was ultimately deemed by the other tracker admins not to be sufficient to balance out the hassles created by his aggressive stance towards closing older issues (which, while unloved, are not automatically invalid). How and how often was Mark reminded about this? If this had happened *without* the prior discussion regarding more appropriate handling of tracker issues, then I would have an issue with it. However, given that the first reaction was to provide additional mentoring, with revocation of privileges only happening when the problems continued, that seems to me like the way this process is *meant* to work. Where was the decision to revoke privileges discussed? Not on any mailing list that I am subscribed to. Was Mark given an ultimatum? Given that this came out rather unfortunately (even if the end result is the best that could have happened) I would recommend that in the future more attention is paid to documenting publicly that someone's being booted out was inevitable, by an exchange of messages on python-dev (or python-committers if we want to limit distribution). And no, I don't think that IRC (where I suspect this happened) is sufficient. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe:
Re: [Python-Dev] Goodbye
On Sep 22, 2010, at 7:17 AM, Guido van Rossum wrote: Where was the decision to revoke privileges discussed? Not on any mailing list that I am subscribed to. It was on IRC. Was Mark given an ultimatum? I sent him a nicely worded email. The tracker privs were set back to the normal level which most participants have (can comment, submit patches, etc. but not close or reprioritize). That would have allowed him to contribute and participate. If that had worked out, it would have been easy to add back close/reprioritize capabilities No one needed to be hurt. Unfortunately, he responded with drama and another dev shut-off his tracker access entirely. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
Guido van Rossum writes: I would recommend that in the future more attention is paid to documenting publicly that someone's being booted out was inevitable, by an exchange of messages on python-dev (or python-committers if we want to limit distribution). And no, I don't think that IRC (where I suspect this happened) is sufficient. +1 on explaining what and why where the committers can see it, and +1 on limiting distribution. The one time I lifted someone's privileges that's the way I did it (by luck, mostly). In hindsight, the fact that it was all done in plain sight of the committers made it easy for us to put the incident behind us. The fact that it was only visible to the committers made it easier mend the relationship later. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On Thu, 23 Sep 2010 00:29:23 +0900 Stephen J. Turnbull step...@xemacs.org wrote: Guido van Rossum writes: I would recommend that in the future more attention is paid to documenting publicly that someone's being booted out was inevitable, by an exchange of messages on python-dev (or python-committers if we want to limit distribution). And no, I don't think that IRC (where I suspect this happened) is sufficient. +1 on explaining what and why where the committers can see it, and +1 on limiting distribution. The one time I lifted someone's privileges that's the way I did it (by luck, mostly). In hindsight, the fact that it was all done in plain sight of the committers made it easy for us to put the incident behind us. The fact that it was only visible to the committers made it easier mend the relationship later. I guess python-committers would have been the best recipient indeed. Sorry for that. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On Wed, Sep 22, 2010 at 8:29 AM, Stephen J. Turnbull step...@xemacs.org wrote: Guido van Rossum writes: I would recommend that in the future more attention is paid to documenting publicly that someone's being booted out was inevitable, by an exchange of messages on python-dev (or python-committers if we want to limit distribution). And no, I don't think that IRC (where I suspect this happened) is sufficient. +1 on explaining what and why where the committers can see it, and +1 on limiting distribution. Agreed on both counts. The one time I lifted someone's privileges that's the way I did it (by luck, mostly). In hindsight, the fact that it was all done in plain sight of the committers made it easy for us to put the incident behind us. The fact that it was only visible to the committers made it easier mend the relationship later. I understand the desire to keep dirty laundry in. I would like to keep it in too. Unfortunately the offending person in this case chose not to; I will not speculate about his motivation. This is not unusual; I can recall several incidents over the past few years (all completely different in every detail of course) where someone blew up publicly and there wasn't much of a chance to keep the incident under wraps. I see it as the risk of doing business in public -- which to me still beats the risk of doing business in back rooms many times over. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
Given that this came out rather unfortunately (even if the end result is the best that could have happened) I would recommend that in the future more attention is paid to documenting publicly that someone's being booted out was inevitable, by an exchange of messages on python-dev (or python-committers if we want to limit distribution). And no, I don't think that IRC (where I suspect this happened) is sufficient. While the community should be informed in public, I think that the actual revocation of privileges should happen in private. People getting such a blue letter often react overly negative, and then regret that their response is recorded in the public. The only downside of this approach is that people may feel that this is a unilateral decision by one committer, then appeal to you (I'm sure you recall cases that went that way :-). Also, I think it would be better to ask the contributor to step back on his own (acknowledging that this isn't really voluntarily), instead of revoking privileges and then informing about that decision. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
Usual disclaimer: I am not a python-dev, just a lurker who sticks his 2c in sometimes... On 22Sep2010 07:17, Guido van Rossum gu...@python.org wrote: | On Wed, Sep 22, 2010 at 4:07 AM, Nick Coghlan ncogh...@gmail.com wrote: | On Wed, Sep 22, 2010 at 8:47 PM, Antoine Pitrou solip...@pitrou.net wrote: | Simply, situations like the above (Mark closing a bug just because | nobody would answer his message on a short delay) have happened | multiple times - despite people opposing, obviously -, and we decided | that it was better to remove his tracker privileges since his | contribution has not really been productive for us. Which sounds like a genuine problem, but ... | There was a whole python-dev thread some time (weeks? months?) ago where | | I think it was the thread No response to posts started (by Mark) on July 31. | | several of us already tried to suggest more fruitful ways of | contributing, suggestions which weren't received very welcomingly AFAIR. | | Yup. In that thread (and others) I see lots of evidence where Mark | responded very negatively (from I disagree entirely to I find this | response quite pathetic) when people explained how we treat the | tracker, and stuck to his guns no matter how many people tried to | explain that he should stop. | | His attitude can be summarized by his Fly back at me if you like. I | don't care about me. I don't care about you. I do care about | Python. | | Which to me sounds defiant and passive-aggressive. I don't want to go | into analyzing, but I expect that Mark has issues that are beyond what | this community can deal with. I've just read that thread. Mark doesn't sound that way to me. I disagree entirely is an entirely valid response, when backed up with argument, such as his immediately following sentence: Perhaps we should simply agree to disagree, but I can't see how having issues that have been sitting for years without any response at all ties in with the current set up works reasonably well I find this response quite pathetic does seem an overreaction to a single point clarification-type post. The Fly back at me if you like. I don't care about me. I don't care about you. I do care about Python. quote I actually think this quite laudable in its way; he's expressing a commitment to getting things done, and a determination to focus on the core issue (response workflow, from the sounds of it) in the face of the emotional responses the disagreement will inevitably produce in the discussions. Again, a follow on statement from that same post: Further, issues don't have to be closed, but what has to happen is that any issue that get raised *MUST* have a response. That's a concrete objection to the status quo for certain old bugs, and one that applies just as well to me own personal email practices (I have a bunch of unreplied-to threads in my supposedly priority inbox; at least these days a mark the things needing a real reply so i can find them later even if I often don't get back to them). I'm not disputing the decision to revoke his priviledges; if he really was closing a lot of bugs that most devs don't think should be closed and could not be dissuaded from doing so I can't see an alternative. I'm just saying I think the tone if his responses in the thread cited isn't as negative to my eye as people are making out. Cheers, -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ 'Soup: This is the one that Kawasaki sent out pictures, that looks so beautiful. Yanagawa: Yes, everybody says it's beautiful - but many problems! 'Soup: But you are not part of the design team, you're just a test rider. Yanagawa: Yes. I just complain. - _Akira Yanagawa Sounds Off_ @ www.amasuperbike.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On 22/09/2010 16:44, Guido van Rossum wrote: On Wed, Sep 22, 2010 at 8:29 AM, Stephen J. Turnbullstep...@xemacs.org wrote: Guido van Rossum writes: I would recommend that in the future more attention is paid to documenting publicly that someone's being booted out was inevitable, by an exchange of messages on python-dev (or python-committers if we want to limit distribution). And no, I don't think that IRC (where I suspect this happened) is sufficient. +1 on explaining what and why where the committers can see it, and +1 on limiting distribution. Agreed on both counts. The one time I lifted someone's privileges that's the way I did it (by luck, mostly). In hindsight, the fact that it was all done in plain sight of the committers made it easy for us to put the incident behind us. The fact that it was only visible to the committers made it easier mend the relationship later. I understand the desire to keep dirty laundry in. I would like to keep it in too. Unfortunately the offending person in this case chose not to; I will not speculate about his motivation. This is not unusual; I can recall several incidents over the past few years (all completely different in every detail of course) where someone blew up publicly and there wasn't much of a chance to keep the incident under wraps. I see it as the risk of doing business in public -- which to me still beats the risk of doing business in back rooms many times over. If you're referring to me I'm extremely offended. Yes or no? Kindest regards. Mark Lawrence. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On 9/22/2010 6:47 AM, Antoine Pitrou wrote: There was a whole python-dev thread some time (weeks? months?) ago where several of us already tried to suggest more fruitful ways of contributing, suggestions which weren't received very welcomingly AFAIR. There were two types of criticisms and suggestions, somewhat contradictory. The first type was something like 'Your tracker work is fine, but your pydev post berating others for not doing the same thing as you is not. Relax, do what you think is worthwhile, and let others decide what they will do. When I reiterated that in private email, he agreed with me and as far as I know he changed his behavior. The second type, which apparently included your response, began Your tracker work is not all good. Change what your are doing If the continuing disagreement and upset with his tracker (versus posting) behavior, to the point of possibly canceling admin privileges, had been brought up for instance on the committers list, I would have suggested to him that the low-hanging fruit had been picked (or discarded) and that a more careful approach was needed for the future. Would that have had any effect? I do not know. Now I understand that opinions over this may vary and involve multiple factors, but I would suggest that at least a bit of mentoring is needed if we want to give privileges early on. (and the amount of mentoring needed can vary wildly from one person to another) Mentoring would be easier if there were clearer and more complete written guidelines. I was under the impression that this was being worked on. It would also be easier if it were clearer who is/are the deputed tracker authority/ies. Not everyone has the same idea about how to handle the various fields and processes. Who decides in cases of disagreement? -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
Yikes - Mark has done terrific work in some very demanding areas, I'd hate to see him feel unwelcome. So that's my advice: find a way to smooth this over. You're welcome ;-) [Guido] ... I understand the desire to keep dirty laundry in. I would like to keep it in too. Unfortunately the offending person in this case chose not to; I will not speculate about his motivation. This is not unusual; I can recall several incidents over the past few years (all completely different in every detail of course) where someone blew up publicly and there wasn't much of a chance to keep the incident under wraps. I see it as the risk of doing business in public -- which to me still beats the risk of doing business in back rooms many times over. [Mark Lawrence] If you're referring to me I'm extremely offended. Yes or no? Have to confess I can't see what's offensive in what Guido wrote there. If you're inclined to feel offended, how about going back to Guido's: Which to me sounds defiant and passive-aggressive. I don't want to go into analyzing, but I expect that Mark has issues that are beyond what this community can deal with. Even I felt a bit offended by that one ;-) speaking-as-one-who-has-issues-no-community-can-deal-with-ly y'rs - tim ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On Wed, Sep 22, 2010 at 5:18 PM, Tim Peters tim.pet...@gmail.com wrote: Yikes - Mark has done terrific work in some very demanding areas, I'd hate to see him feel unwelcome. So that's my advice: find a way to smooth this over. You're welcome ;-) [Guido] ... I understand the desire to keep dirty laundry in. I would like to keep it in too. Unfortunately the offending person in this case chose not to; I will not speculate about his motivation. This is not unusual; I can recall several incidents over the past few years (all completely different in every detail of course) where someone blew up publicly and there wasn't much of a chance to keep the incident under wraps. I see it as the risk of doing business in public -- which to me still beats the risk of doing business in back rooms many times over. [Mark Lawrence] If you're referring to me I'm extremely offended. Yes or no? Have to confess I can't see what's offensive in what Guido wrote there. If you're inclined to feel offended, how about going back to Guido's: Which to me sounds defiant and passive-aggressive. I don't want to go into analyzing, but I expect that Mark has issues that are beyond what this community can deal with. Even I felt a bit offended by that one ;-) That was not one of my finer moments, and I apologize. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On Wed, 22 Sep 2010 19:18:35 -0400, Terry Reedy tjre...@udel.edu wrote: On 9/22/2010 6:47 AM, Antoine Pitrou wrote: Now I understand that opinions over this may vary and involve multiple factors, but I would suggest that at least a bit of mentoring is needed if we want to give privileges early on. (and the amount of mentoring needed can vary wildly from one person to another) Mentoring would be easier if there were clearer and more complete written guidelines. I was under the impression that this was being worked on. It would also be easier if it were clearer who is/are the Brett is planning to work on it. Because he is, I suspect everyone else is waiting for that, instead of working on it now. Just one of those things. (I believe his target is January-ish?) deputed tracker authority/ies. Not everyone has the same idea about how to handle the various fields and processes. Who decides in cases of disagreement? We discussed this a while back and I don't think we really have a tracker BD. Brett and Martin come closest, but mostly we just sort of evolve a rough consensus. I think once Brett reduces that operating consensus to a written document things will be clearer. --David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On 9/22/2010 8:31 PM, Guido van Rossum wrote: [...] Which to me sounds defiant and passive-aggressive. I don't want to go into analyzing, but I expect that Mark has issues that are beyond what this community can deal with. Even I felt a bit offended by that one ;-) That was not one of my finer moments, and I apologize. So even after losing his tracker privileges Mark is still managing to find ways to improve the Python community ;-) regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On Wed, Sep 22, 2010 at 18:24, R. David Murray rdmur...@bitdance.com wrote: On Wed, 22 Sep 2010 19:18:35 -0400, Terry Reedy tjre...@udel.edu wrote: On 9/22/2010 6:47 AM, Antoine Pitrou wrote: Now I understand that opinions over this may vary and involve multiple factors, but I would suggest that at least a bit of mentoring is needed if we want to give privileges early on. (and the amount of mentoring needed can vary wildly from one person to another) Mentoring would be easier if there were clearer and more complete written guidelines. I was under the impression that this was being worked on. It would also be easier if it were clearer who is/are the Brett is planning to work on it. Because he is, I suspect everyone else is waiting for that, instead of working on it now. Just one of those things. (I believe his target is January-ish?) Yep. I am planning on starting my two month PSF grant in January and the first thing on the agenda is a complete rewrite of the developer docs and moving them into the Doc/ directory (after that is managing code in Python 2/3 HOWTO and then after that most likely testing stuff, but maybe Python 3 stdlib fixes instead if that is deemed more important). -Brett deputed tracker authority/ies. Not everyone has the same idea about how to handle the various fields and processes. Who decides in cases of disagreement? We discussed this a while back and I don't think we really have a tracker BD. Brett and Martin come closest, but mostly we just sort of evolve a rough consensus. I think once Brett reduces that operating consensus to a written document things will be clearer. --David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On Thu, 23 Sep 2010 10:18:39 am Tim Peters wrote: Yikes - Mark has done terrific work in some very demanding areas, I'd hate to see him feel unwelcome. So that's my advice: find a way to smooth this over. You're welcome ;-) I'd like to second that. Mark has been pushy, annoying and demanding, although he has his bad points too *grins*. Seriously, Mark has brought a remarkable amount of energy to the tracker, for good and bad. The good shouldn't give him a Get Out Of Jail Free card forever, but in the absence of any knowledge of what lead to Mark's tracker privileges being revoked, I have no objections in principle to giving him a second chance if the devs decide that is acceptable and Mark is willing. (Not that my objections carry much weight.) Either way, I would like to publicly thank Mark for his efforts and wish him the best for the future. [...] Have to confess I can't see what's offensive in what Guido wrote there. If you're inclined to feel offended, how about going back to Guido's: Which to me sounds defiant and passive-aggressive. I don't want to go into analyzing, but I expect that Mark has issues that are beyond what this community can deal with. Even I felt a bit offended by that one ;-) I don't see why. Mark's emails often do sound defiant and passive-aggressive. Is that something we're supposed to ignore? And as for issues, Mark himself has explicitly and publicly mentioned them on this very list, and we *can't* deal with them. Nor should we be expected to. Mark has done good work, dealing with many issues in the tracker during a remarkably short time. But he's also managed to annoy and upset a number of people in a remarkably short time too. The long term health of Python depends more on the community than the existence of a few bugs more or less. -- Steven D'Aprano ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
Cameron Simpson writes: I've just read that thread. Mark doesn't sound that way to me. I disagree entirely is an entirely valid response, when backed up with argument, such as his immediately following sentence: Perhaps we should simply agree to disagree, Agreeing to disagree *on actions* does not work with shared resources, and the tracker is a shared resource. It's not a valid response here. According to reports, his disagreement *did* extend to action. I find this response quite pathetic does seem an overreaction to a single point clarification-type post. The Fly back at me if you like. I don't care about me. I don't care about you. I do care about Python. quote I actually think this quite laudable in its way; he's expressing a commitment to getting things done, and a determination to focus on the core issue (response workflow, from the sounds of it) in the face of the emotional responses the disagreement will inevitably produce in the discussions. Expressing a commitment and emotional discussion are not problems worthy of even thinking about changing privileges. The problem is that (according to reports) he *imposed* his opinion on all the other tracker workers by making changes to the public database (ie, closing bugs), after being told by several people that the consensus was otherwise. And did this several times. While this was not clearly expressed in several of the key posts in this thread, I suspect that this is what was meant by other ways are more fruitful and Guido's now retracted psychoanalytic comment. There is a delicate balance to be kept between he who does the work makes the decisions and polluting the common pool. In this case, the balance was clearly upset. Triaging and closing bug reports are not the only functions of the tracker, and in fact they are subsidiary to actual bug-fixing work. It's pretty clear to me that if a triager disagrees with the priorities of the bug fixers, his only recourse is public discussion, and to do what he personally can to respond to issues. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Goodbye
I'm rather sad to have been sacked, but such is life. I won't be doing any more work on the bug tracker for obvious reasons, but hope that you who have managed to keep your voluntary jobs manage to keep Python going. Kindest regards. Mark Lawrence. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On Tue, Sep 21, 2010 at 7:58 PM, Mark Lawrence breamore...@yahoo.co.uk wrote: I'm rather sad to have been sacked, but such is life. I won't be doing any more work on the bug tracker for obvious reasons, but hope that you who have managed to keep your voluntary jobs manage to keep Python going. Umm, what? You mean http://bugs.python.org/issue2180 ? Mark, please stop closing these based on age. The needs to be a determination whether this is a valid bug. If so, then a patch is needed. If not, it can be closed. Am I missing something? -Jack ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
