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.
On Tue, Sep 21, 2010 at 7:58 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
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
On Tue, 21 Sep 2010 20:16:52 -0400 Jack Diederich <jackdied@gmail.com> 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) Regards Antoine.
On Wed, Sep 22, 2010 at 8:47 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
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 | ncoghlan@gmail.com | Brisbane, Australia
On Wed, Sep 22, 2010 at 4:07 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
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.
Right, that was my impression from the issues he touched on which I happened to be subscribed.
How and how often was Mark reminded about this?
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)
On 22/09/2010 15:33, darren@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
-- 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.
2010/9/22 Guido van Rossum <guido@python.org>:
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.
Indeed, it was on IRC.
We'll note that for the future. -- Regards, Benjamin
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
Guido van Rossum writes:
+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.
On Wed, Sep 22, 2010 at 8:29 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Agreed on both counts.
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)
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]
[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
On 9/22/2010 8:31 PM, Guido van Rossum wrote: [...]
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, 2010 http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/
On Thu, 23 Sep 2010 10:18:39 am Tim Peters wrote:
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. [...]
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
Am 23.09.2010 04:35, schrieb Steven D'Aprano:
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.
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
Usual disclaimer: I am not a python-dev, just a lurker who sticks his 2c in sometimes... On 22Sep2010 07:17, Guido van Rossum <guido@python.org> wrote: | On Wed, Sep 22, 2010 at 4:07 AM, Nick Coghlan <ncoghlan@gmail.com> wrote: | > On Wed, Sep 22, 2010 at 8:47 PM, Antoine Pitrou <solipsis@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 <cs@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
Cameron Simpson writes:
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.
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.
On Thu, 23 Sep 2010 13:32:07 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote:
+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.
On 23/09/2010 10:59, Antoine Pitrou wrote:
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
-- 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.
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
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.)
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
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
On 23/09/2010 13:28, "Martin v. Löwis" wrote:
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
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
On Thu, 23 Sep 2010 11:50:26 -0600, "Zooko O'Whielacronx" <zooko@zooko.com> wrote:
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
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 docs@python.
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
On 9/23/2010 1:44 PM, Terry Reedy wrote:
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".
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, 2010 http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/
On Fri, Sep 24, 2010 at 3:44 AM, Terry Reedy <tjreedy@udel.edu> wrote:
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 | ncoghlan@gmail.com | Brisbane, Australia
On 9/22/2010 6:47 AM, Antoine Pitrou wrote:
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.
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
On Wed, 22 Sep 2010 19:18:35 -0400, Terry Reedy <tjreedy@udel.edu> wrote:
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?)
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
On Wed, Sep 22, 2010 at 18:24, R. David Murray <rdmurray@bitdance.com> wrote:
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
On Sep 22, 2010, at 6:24 PM, R. David Murray wrote:
IMO, Benjamin and Antoine are the closest. They devote a substantial portion of their lives to Python and have been our most active contributors in the last year. They read almost every tracker post, read every check-in, and continuously monitor the IRC channel. Raymond
On Wed, Sep 22, 2010 at 11:46 PM, Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
Off topic-er. Does anyone have scripts that pull data on how many committers commit or how many trac admins admin? I'm not asking for punitive reasons - I'd be the first against the wall - but I wouldn't mind graphing it. Power law, methinks. With big, confounding, and jumbley spikes in the Spring for PyCon. Likewise for mailing list subscriptions. Personally I've gone back and forth between subscribing to everything (-list -dev -commits -bugs -ideas, et al) and subscribing to almost nothing. -Jack
Am 23.09.2010 07:32, schrieb Jack Diederich:
This should be easy to do with a hg repo such as the test conversion one on hg.python.org -- the "activity" extension already does the graphing, and I'm sure it can easily be tweaked to your liking. http://www.freehackers.org/thomas/2008/10/31/activity-extension-for-mercuria... cheers, Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
On Thursday 23 September 2010 08:36:47 Georg Brandl wrote:
Hi all, This blog entry is old, and I have improved 'hg activity' since then, for example the extension can now display several graphs, splitting the activity by authors, branches, files, ... And, of course, I would be very happy to help 'tweaking' the script for the python community. best wishes, Thomas ps: i'm not subscribed to python-dev. -- Thomas Capricelli <orzel@freehackers.org> http://www.freehackers.org/thomas
In article <AANLkTi=BLcBDzE7OR7YnPnQcBmLxAEiDhejeRkXsogRp@mail.gmail.com>, Jack Diederich <jackdied@gmail.com> wrote:
Mailing list subscription data could be very misleading as people follow this list (and other Python-related lists) through other interfaces, such as those provided by gmane.org (NNTP, RSS, web). Helps to keep the mailbox clutter down. -- Ned Deily, nad@acm.org
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
Am 23.09.2010 09:18, schrieb "Martin v. Löwis":
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.
On 23/09/2010 09:46, Georg Brandl wrote:
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
On 23/09/2010 10:38, "Martin v. Löwis" wrote:
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
Am 23.09.2010 11:43, schrieb Tim Golden:
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
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.
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
Am 23.09.2010 19:22, schrieb Terry Reedy:
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.
On 9/23/2010 6:17 PM, Nick Coghlan wrote:
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
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 <tjreedy@udel.edu> wrote:
On 9/23/2010 7:12 PM, darren@ontrenet.com wrote:
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.
-- Terry Jan Reedy
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
In article <4C9C6A6F.6010202@netwok.org>, Éric Araujo <merwok@netwok.org> wrote:
I believe there is another separate use case for the versions field that hasn't been mentioned yet: for issues with "release blocker" priority, the versions field is often used to identify the upcoming release for which a resolution is deemed mandatory. However, having a single versions field is not totally satisfactory for this, particularly when - as has happened in the recent past - two different release cycles overlap (say, Python 2.7.x and 3.2.y). A given issue may or may not apply to both, it may be a "release blocker" for one or both, and, if both, a fix may be checked-in for one branch but not the other. The release managers for the two releases may end up using the one priority field and the one set of version fields for conflicting purposes. It certainly makes it more difficult to automate a tracking report of exactly what are the release blocker issues for a specific release. Besides adding fields to the database for an issue, there are other ways to handle the ambiguity, of course. The simplest might be to just open a separate duplicate issue for each additional release blocked. Presumably that level of detail might only be needed in the endgame of a release, beta or rc stages. It still places a restriction on the use of the version field and possibly other fields. In issue workflow documentation, there should be some description of how "release blocker" should work, perhaps including something along the lines of "once a release enters stage <x>, 'release blocker' priority should only be changed with the approval of the release manager". -- Ned Deily, nad@acm.org
On Fri, Sep 24, 2010 at 10:26 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
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 | ncoghlan@gmail.com | Brisbane, Australia
On Sat, Sep 25, 2010 at 12:31 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
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 | ncoghlan@gmail.com | Brisbane, Australia
On Sat, Sep 25, 2010 at 12:50 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
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 | ncoghlan@gmail.com | Brisbane, Australia
I think most people won't intuitively file performance issues as "feature requests", since it doesn't sound like a feature.
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.
On Sat, Sep 25, 2010 at 1:12 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Agreed.
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 | ncoghlan@gmail.com | Brisbane, Australia
On 9/24/2010 10:50 AM, Antoine Pitrou wrote:
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, 2010 http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/
É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-dev@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.
Le 23/09/2010 19:22, Terry Reedy a écrit :
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
Am 23.09.2010 22:51, schrieb Éric Araujo:
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.
Le 23/09/2010 22:51, Éric Araujo a écrit :
There has been no further feedback after Georg (thanks Georg), so I went ahead and set “3rd party” for distutils2 bugs instead of 2.5-3.2, for all the aforementioned reasons. Bugs applying to distutils and distutils2 have versions 2.7, 3.1, 3.2, 3rd party so that the forward-port is not forgotten. If you commit a change to distutils, sysconfig or pkgutil, it’s fine to assign the forward-port to me or, if you can use Mercurial, to publish a changeset somewhere and request a pull/import. (Those versions changes sent a lot of email, but this had to be done. Sorry for the inconvenience.) Thanks again to Terry and Mark for their triage work. Hope this helps! Kind regards
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
"Martin v. Löwis" writes:
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.
On 9/24/2010 1:41 AM, Stephen J. Turnbull wrote:
There is also the matter of letting people start with something they feel condident with and grow into more complicated tasks.
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
On Wed, 22 Sep 2010 21:24:49 -0400 "R. David Murray" <rdmurray@bitdance.com> wrote:
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.
On 9/21/2010 7:58 PM, Mark Lawrence wrote:
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, 2010 http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/
On Tue, Sep 21, 2010 at 7:58 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
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
On Tue, 21 Sep 2010 20:16:52 -0400 Jack Diederich <jackdied@gmail.com> 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) Regards Antoine.
On Wed, Sep 22, 2010 at 8:47 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
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 | ncoghlan@gmail.com | Brisbane, Australia
On Wed, Sep 22, 2010 at 4:07 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
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.
Right, that was my impression from the issues he touched on which I happened to be subscribed.
How and how often was Mark reminded about this?
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)
On 22/09/2010 15:33, darren@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
-- 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.
2010/9/22 Guido van Rossum <guido@python.org>:
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.
Indeed, it was on IRC.
We'll note that for the future. -- Regards, Benjamin
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
Guido van Rossum writes:
+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.
On Wed, Sep 22, 2010 at 8:29 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Agreed on both counts.
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)
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]
[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
On 9/22/2010 8:31 PM, Guido van Rossum wrote: [...]
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, 2010 http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/
On Thu, 23 Sep 2010 10:18:39 am Tim Peters wrote:
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. [...]
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
Am 23.09.2010 04:35, schrieb Steven D'Aprano:
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.
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
Usual disclaimer: I am not a python-dev, just a lurker who sticks his 2c in sometimes... On 22Sep2010 07:17, Guido van Rossum <guido@python.org> wrote: | On Wed, Sep 22, 2010 at 4:07 AM, Nick Coghlan <ncoghlan@gmail.com> wrote: | > On Wed, Sep 22, 2010 at 8:47 PM, Antoine Pitrou <solipsis@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 <cs@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
Cameron Simpson writes:
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.
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.
On Thu, 23 Sep 2010 13:32:07 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote:
+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.
On 23/09/2010 10:59, Antoine Pitrou wrote:
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
-- 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.
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
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.)
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
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
On 23/09/2010 13:28, "Martin v. Löwis" wrote:
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
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
On Thu, 23 Sep 2010 11:50:26 -0600, "Zooko O'Whielacronx" <zooko@zooko.com> wrote:
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
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 docs@python.
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
On 9/23/2010 1:44 PM, Terry Reedy wrote:
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".
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, 2010 http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/
On Fri, Sep 24, 2010 at 3:44 AM, Terry Reedy <tjreedy@udel.edu> wrote:
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 | ncoghlan@gmail.com | Brisbane, Australia
On 9/22/2010 6:47 AM, Antoine Pitrou wrote:
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.
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
On Wed, 22 Sep 2010 19:18:35 -0400, Terry Reedy <tjreedy@udel.edu> wrote:
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?)
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
On Wed, Sep 22, 2010 at 18:24, R. David Murray <rdmurray@bitdance.com> wrote:
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
On Sep 22, 2010, at 6:24 PM, R. David Murray wrote:
IMO, Benjamin and Antoine are the closest. They devote a substantial portion of their lives to Python and have been our most active contributors in the last year. They read almost every tracker post, read every check-in, and continuously monitor the IRC channel. Raymond
On Wed, Sep 22, 2010 at 11:46 PM, Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
Off topic-er. Does anyone have scripts that pull data on how many committers commit or how many trac admins admin? I'm not asking for punitive reasons - I'd be the first against the wall - but I wouldn't mind graphing it. Power law, methinks. With big, confounding, and jumbley spikes in the Spring for PyCon. Likewise for mailing list subscriptions. Personally I've gone back and forth between subscribing to everything (-list -dev -commits -bugs -ideas, et al) and subscribing to almost nothing. -Jack
Am 23.09.2010 07:32, schrieb Jack Diederich:
This should be easy to do with a hg repo such as the test conversion one on hg.python.org -- the "activity" extension already does the graphing, and I'm sure it can easily be tweaked to your liking. http://www.freehackers.org/thomas/2008/10/31/activity-extension-for-mercuria... cheers, Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
On Thursday 23 September 2010 08:36:47 Georg Brandl wrote:
Hi all, This blog entry is old, and I have improved 'hg activity' since then, for example the extension can now display several graphs, splitting the activity by authors, branches, files, ... And, of course, I would be very happy to help 'tweaking' the script for the python community. best wishes, Thomas ps: i'm not subscribed to python-dev. -- Thomas Capricelli <orzel@freehackers.org> http://www.freehackers.org/thomas
In article <AANLkTi=BLcBDzE7OR7YnPnQcBmLxAEiDhejeRkXsogRp@mail.gmail.com>, Jack Diederich <jackdied@gmail.com> wrote:
Mailing list subscription data could be very misleading as people follow this list (and other Python-related lists) through other interfaces, such as those provided by gmane.org (NNTP, RSS, web). Helps to keep the mailbox clutter down. -- Ned Deily, nad@acm.org
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
Am 23.09.2010 09:18, schrieb "Martin v. Löwis":
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.
On 23/09/2010 09:46, Georg Brandl wrote:
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
On 23/09/2010 10:38, "Martin v. Löwis" wrote:
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
Am 23.09.2010 11:43, schrieb Tim Golden:
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
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.
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
Am 23.09.2010 19:22, schrieb Terry Reedy:
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.
On Fri, Sep 24, 2010 at 5:50 AM, Georg Brandl <g.brandl@gmx.net> wrote:
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 | ncoghlan@gmail.com | Brisbane, Australia
On 9/23/2010 6:17 PM, Nick Coghlan wrote:
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
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 <tjreedy@udel.edu> wrote:
On 9/23/2010 7:12 PM, darren@ontrenet.com wrote:
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.
-- Terry Jan Reedy
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
In article <4C9C6A6F.6010202@netwok.org>, Éric Araujo <merwok@netwok.org> wrote:
I believe there is another separate use case for the versions field that hasn't been mentioned yet: for issues with "release blocker" priority, the versions field is often used to identify the upcoming release for which a resolution is deemed mandatory. However, having a single versions field is not totally satisfactory for this, particularly when - as has happened in the recent past - two different release cycles overlap (say, Python 2.7.x and 3.2.y). A given issue may or may not apply to both, it may be a "release blocker" for one or both, and, if both, a fix may be checked-in for one branch but not the other. The release managers for the two releases may end up using the one priority field and the one set of version fields for conflicting purposes. It certainly makes it more difficult to automate a tracking report of exactly what are the release blocker issues for a specific release. Besides adding fields to the database for an issue, there are other ways to handle the ambiguity, of course. The simplest might be to just open a separate duplicate issue for each additional release blocked. Presumably that level of detail might only be needed in the endgame of a release, beta or rc stages. It still places a restriction on the use of the version field and possibly other fields. In issue workflow documentation, there should be some description of how "release blocker" should work, perhaps including something along the lines of "once a release enters stage <x>, 'release blocker' priority should only be changed with the approval of the release manager". -- Ned Deily, nad@acm.org
On Fri, Sep 24, 2010 at 10:26 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
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 | ncoghlan@gmail.com | Brisbane, Australia
On Sat, Sep 25, 2010 at 12:31 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
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 | ncoghlan@gmail.com | Brisbane, Australia
On Sat, Sep 25, 2010 at 12:50 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
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 | ncoghlan@gmail.com | Brisbane, Australia
I think most people won't intuitively file performance issues as "feature requests", since it doesn't sound like a feature.
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.
On Sat, Sep 25, 2010 at 1:12 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Agreed.
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 | ncoghlan@gmail.com | Brisbane, Australia
On 9/24/2010 10:50 AM, Antoine Pitrou wrote:
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, 2010 http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/
É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-dev@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.
Le 23/09/2010 19:22, Terry Reedy a écrit :
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
Am 23.09.2010 22:51, schrieb Éric Araujo:
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.
Le 23/09/2010 22:51, Éric Araujo a écrit :
There has been no further feedback after Georg (thanks Georg), so I went ahead and set “3rd party” for distutils2 bugs instead of 2.5-3.2, for all the aforementioned reasons. Bugs applying to distutils and distutils2 have versions 2.7, 3.1, 3.2, 3rd party so that the forward-port is not forgotten. If you commit a change to distutils, sysconfig or pkgutil, it’s fine to assign the forward-port to me or, if you can use Mercurial, to publish a changeset somewhere and request a pull/import. (Those versions changes sent a lot of email, but this had to be done. Sorry for the inconvenience.) Thanks again to Terry and Mark for their triage work. Hope this helps! Kind regards
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
"Martin v. Löwis" writes:
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.
On 9/24/2010 1:41 AM, Stephen J. Turnbull wrote:
There is also the matter of letting people start with something they feel condident with and grow into more complicated tasks.
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
On Wed, 22 Sep 2010 21:24:49 -0400 "R. David Murray" <rdmurray@bitdance.com> wrote:
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.
On 9/21/2010 7:58 PM, Mark Lawrence wrote:
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, 2010 http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/
participants (24)
-
"Martin v. Löwis" -
Antoine Pitrou -
Benjamin Peterson -
Brett Cannon -
Cameron Simpson -
darren＠ontrenet.com -
Georg Brandl -
Guido van Rossum -
Jack Diederich -
Mark Lawrence -
Michael Foord -
Ned Deily -
Nick Coghlan -
R. David Murray -
Raymond Hettinger -
Stephen J. Turnbull -
Steve Holden -
Steven D'Aprano -
Terry Reedy -
Thomas Capricelli -
Tim Golden -
Tim Peters -
Zooko O'Whielacronx -
Éric Araujo