Keywords are generally better than a restricted vocabulary for richness
of content, but worse for finding the appropriate search term. You pays
yer money and takes yer chance.
I think you are unaware what a roundup keyword is, here.
But without any smarts being applied to the problem
it's
On Sat, Sep 25, 2010 at 1:12 AM, Antoine Pitrou solip...@pitrou.net wrote:
But how should a performance improvement be filed? Bug? Feature request?
Or should feature request be renamed improvement?
It's a feature request (since we won't backport it unless there is a
genuine performance
On 9/26/2010 7:43 AM, Nick Coghlan wrote:
Yep, hence why I think the basic bug, feature, other split may be a
good way to go. It's a quick and easy decision most of the time
(including a clear choice for I don't know if this is a bug or not),
and makes a meaningful procedural distinction (bugs
É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
On 9/24/2010 10:50 AM, Antoine Pitrou wrote:
Le samedi 25 septembre 2010 à 00:42 +1000, Nick Coghlan a écrit :
I have often used searches on performance or resource usage to find
what was needing a review or a patch. I think it would be a mistake to
remove those two categories.
That purpose
Am 23.09.2010 22:51, schrieb Éric Araujo:
Le 23/09/2010 19:22, Terry Reedy a écrit :
As of just now, if you were to wonder What (security) bugs are open for
2.5 and search on open 2.5 issues, you would get a list of 44 issues.
It is only 44 instead of hundreds because of the work I and Mark
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
On Fri, 24 Sep 2010 11:07:59 +0200
Éric Araujo mer...@netwok.org wrote:
How about revamping the type/versions fields?
Issue type
() Feature request (blocked by moratorium: () yes () no)
() Bug (found in: [] 2.7 [] 3.1 [] py3k)
() Security bug (found in: [] 2.5 [] 2.6 [] 2.7 [] 3.1 [] py3k)
On Fri, Sep 24, 2010 at 10:26 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Fri, 24 Sep 2010 11:07:59 +0200
Éric Araujo mer...@netwok.org wrote:
How about revamping the type/versions fields?
Issue type
() Feature request (blocked by moratorium: () yes () no)
() Bug (found in: [] 2.7 []
But we also have performance, crash, resource usage... Are we
suggesting we devise a separate list box for each of these issue types?
I must admit, I've never actually found much use for those additional
options. If I'm flagging a bug I'll nearly always mark it behaviour,
otherwise I'll
On Sat, Sep 25, 2010 at 12:31 AM, Antoine Pitrou solip...@pitrou.net wrote:
But we also have performance, crash, resource usage... Are we
suggesting we devise a separate list box for each of these issue types?
I must admit, I've never actually found much use for those additional
options.
Le samedi 25 septembre 2010 à 00:42 +1000, Nick Coghlan a écrit :
I have often used searches on performance or resource usage to find
what was needing a review or a patch. I think it would be a mistake to
remove those two categories.
That purpose would be served just as well by keywords
On Sat, Sep 25, 2010 at 12:50 AM, Antoine Pitrou solip...@pitrou.net wrote:
Le samedi 25 septembre 2010 à 00:42 +1000, Nick Coghlan a écrit :
I have often used searches on performance or resource usage to find
what was needing a review or a patch. I think it would be a mistake to
remove
But how should a performance improvement be filed? Bug? Feature request?
Or should feature request be renamed improvement?
It's a feature request (since we won't backport it unless there is a
genuine performance problem being addressed as a bug fix). Whether
that warrants changing the
On 9/24/2010 1:41 AM, Stephen J. Turnbull wrote:
Yes, and we'd all like more people to do more real work. But not
everybody has the time or skills. I think this is a case where
agreeing to disagree is the best we can do.
There is also the matter of letting people start with something they
Am 23.09.2010 04:35, schrieb Steven D'Aprano:
On Thu, 23 Sep 2010 10:18:39 am Tim Peters wrote:
Yikes - Mark has done terrific work in some very demanding areas,
I'd hate to see him feel unwelcome. So that's my advice: find a
way to smooth this over. You're welcome ;-)
I'd like to
deputed tracker authority/ies. Not everyone has the same idea about how
to handle the various fields and processes. Who decides in cases of
disagreement?
We discussed this a while back and I don't think we really have a tracker
BD. Brett and Martin come closest, but mostly we just sort
Am 23.09.2010 09:18, schrieb Martin v. Löwis:
deputed tracker authority/ies. Not everyone has the same idea about how
to handle the various fields and processes. Who decides in cases of
disagreement?
We discussed this a while back and I don't think we really have a tracker
BD. Brett and
On 23/09/2010 09:46, Georg Brandl wrote:
Am 23.09.2010 09:18, schrieb Martin v. Löwis:
I personally think that the tracker fields and how they should be set is
of minor importance. If there is a bug in Python, the most useful
contribution is to submit a fix (or provide a rationale why this is
Let me ask a question which I don't think has been asked in this
thread: are there guidelines for tracker-trawlers? I'm never sure
where to look for this kind of thing myself. If there's nothing,
I'm happy to pen a dos-and-donts (which I might do anyway, simply
as a blog entry...)
Can you
On 23/09/2010 10:38, Martin v. Löwis wrote:
Let me ask a question which I don't think has been asked in this
thread: are there guidelines for tracker-trawlers? I'm never sure
where to look for this kind of thing myself. If there's nothing,
I'm happy to pen a dos-and-donts (which I might do
On Thu, 23 Sep 2010 13:32:07 +0900
Stephen J. Turnbull step...@xemacs.org wrote:
Triaging and closing bug reports are
not the only functions of the tracker, and in fact they are subsidiary
to actual bug-fixing work.
+1. What we really need is people analyzing issues, posting patches or
On Wed, 22 Sep 2010 21:24:49 -0400
R. David Murray rdmur...@bitdance.com wrote:
deputed tracker authority/ies. Not everyone has the same idea about how
to handle the various fields and processes. Who decides in cases of
disagreement?
We discussed this a while back and I don't think we
Am 23.09.2010 11:43, schrieb Tim Golden:
On 23/09/2010 10:38, Martin v. Löwis wrote:
Let me ask a question which I don't think has been asked in this
thread: are there guidelines for tracker-trawlers? I'm never sure
where to look for this kind of thing myself. If there's nothing,
I'm happy to
On 23/09/2010 10:59, Antoine Pitrou wrote:
On Thu, 23 Sep 2010 13:32:07 +0900
Stephen J. Turnbullstep...@xemacs.org wrote:
Triaging and closing bug reports are
not the only functions of the tracker, and in fact they are subsidiary
to actual bug-fixing work.
+1. What we really need is people
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
On 23/09/2010 13:11, Martin v. Löwis wrote:
make sure the issue is assigned to the right person if appropriate
-1. We typically don't assign issues to others.
Some people have requested to be assigned to issues. (Myself for
unittest, Ronald for Mac OS X issues etc.)
add relevant keywords
add relevant keywords to make it easier to find in searches
-0. Going through old issues just to make sure the keywords are right
seems wasteful.
Hard as it may be to believe, we do have (and are trying to cultivate)
people who want to contribute to Python and start by searching for
On 23/09/2010 13:28, Martin v. Löwis wrote:
add relevant keywords to make it easier to find in searches
-0. Going through old issues just to make sure the keywords are right
seems wasteful.
Hard as it may be to believe, we do have (and are trying to cultivate)
people who want to contribute
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
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
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
On 9/23/2010 1:44 PM, Terry Reedy wrote:
On 9/23/2010 8:11 AM, Martin v. Löwis wrote:
make sure the issue is assigned to the right person if appropriate
-1. We typically don't assign issues to others.
What I and Mark (that I know of) did in that respect was to assign doc
issues, including
On Thu, 23 Sep 2010 11:50:26 -0600, Zooko O'Whielacronx zo...@zooko.com
wrote:
Also, I would like to point out that, not having read the other
traffic that this thread alludes to, either from earlier mailing list
threads or from IRC, I don't really understand what exactly Mark did
wrong. The
Am 23.09.2010 19:22, schrieb Terry Reedy:
Asking every now and then is this still an issue, or setting
the version number, doesn't really advance the issue.
Numerous issues have been advanced by the questions I and Mark have
asked. Some were legitimately closed as out of date (the bug
Le 23/09/2010 19:22, Terry Reedy a écrit :
As of just now, if you were to wonder What (security) bugs are open for
2.5 and search on open 2.5 issues, you would get a list of 44 issues.
It is only 44 instead of hundreds because of the work I and Mark have
done in the last 4 months. It it 44
Asking every now and then is this still an issue, or setting
the version number, doesn't really advance the issue.
Setting Versions properly helps anyone searching for issues relevant to
a particular version. If having a field set properly does not matter,
then is should not be there. Are
On 9/23/2010 3:50 PM, Georg Brandl wrote:
ISTM that the versions field is not very useful if the other fields are
filled accurately.
For example, feature requests almost always only belong to the current trunk.
Yes, for features that fall under the moratorium, the versions field would
be
On Fri, Sep 24, 2010 at 5:50 AM, Georg Brandl g.bra...@gmx.net wrote:
Setting Versions properly helps anyone searching for issues relevant to
a particular version. If having a field set properly does not matter,
then is should not be there. Are you suggesting that Versions be deleted?
ISTM
On Fri, Sep 24, 2010 at 3:44 AM, Terry Reedy tjre...@udel.edu wrote:
On 9/23/2010 8:11 AM, Martin v. Löwis wrote:
make sure the issue is assigned to the right person if appropriate
-1. We typically don't assign issues to others.
What I and Mark (that I know of) did in that respect was to
On 9/23/2010 6:17 PM, Nick Coghlan wrote:
On Fri, Sep 24, 2010 at 5:50 AM, Georg Brandlg.bra...@gmx.net wrote:
Setting Versions properly helps anyone searching for issues relevant to
a particular version. If having a field set properly does not matter,
then is should not be there. Are you
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
On 9/23/2010 7:12 PM, dar...@ontrenet.com wrote:
So if there turns out to be a major security hole or sever bug in 2.7,
then it shouldn't be filed against 2.7? and fixed in a 2.7.x sort of
branch?
In that case, would you just suggest everyone using 2.7 to jump to 3.x?
As long as a 2.x version
Martin v. Löwis writes:
I didn't say the field does not matter. I said adjusting it doesn't
advance the issue. Anybody *really* working on the issue might
choose to update it, or might choose to leave it incorrect when the
issue is going to be closed, anyway.
Yes, and we'd all like more
On Tue, 21 Sep 2010 20:16:52 -0400
Jack Diederich jackd...@gmail.com wrote:
On Tue, Sep 21, 2010 at 7:58 PM, Mark Lawrence breamore...@yahoo.co.uk
wrote:
I'm rather sad to have been sacked, but such is life. I won't be doing any
more work on the bug tracker for obvious reasons, but hope
On Wed, Sep 22, 2010 at 8:47 PM, Antoine Pitrou solip...@pitrou.net wrote:
Simply, situations like the above (Mark closing a bug just because
nobody would answer his message on a short delay) have happened
multiple times - despite people opposing, obviously -, and we decided
that it was better
On 9/21/2010 7:58 PM, Mark Lawrence wrote:
I'm rather sad to have been sacked, but such is life. I won't be doing
any more work on the bug tracker for obvious reasons, but hope that you
who have managed to keep your voluntary jobs manage to keep Python going.
Kindest regards.
Mark
On Wed, Sep 22, 2010 at 4:07 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Wed, Sep 22, 2010 at 8:47 PM, Antoine Pitrou solip...@pitrou.net wrote:
Simply, situations like the above (Mark closing a bug just because
nobody would answer his message on a short delay) have happened
multiple times -
If you guys continue to make a public jury of this, no one else will want
to step into that role
On Wed, Sep 22, 2010 at 4:07 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Wed, Sep 22, 2010 at 8:47 PM, Antoine Pitrou solip...@pitrou.net
wrote:
Simply, situations like the above (Mark
2010/9/22 Guido van Rossum gu...@python.org:
On Wed, Sep 22, 2010 at 4:07 AM, Nick Coghlan ncogh...@gmail.com wrote:
A number of lingering issues that would have otherwise continued
lingering did indeed get closed. That work is still appreciated, even
if it was ultimately deemed by the other
On 22/09/2010 15:33, dar...@ontrenet.com wrote:
If you guys continue to make a public jury of this, no one else will want
to step into that role
One of the perhaps-downsides of projects with an open community and open
development processes is that any dirty-laundry there might be tends
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
Guido van Rossum writes:
I would recommend that in the future more attention is paid to
documenting publicly that someone's being booted out was
inevitable, by an exchange of messages on python-dev (or
python-committers if we want to limit distribution). And no, I
don't think that IRC
On Thu, 23 Sep 2010 00:29:23 +0900
Stephen J. Turnbull step...@xemacs.org wrote:
Guido van Rossum writes:
I would recommend that in the future more attention is paid to
documenting publicly that someone's being booted out was
inevitable, by an exchange of messages on python-dev (or
On Wed, Sep 22, 2010 at 8:29 AM, Stephen J. Turnbull step...@xemacs.org wrote:
Guido van Rossum writes:
I would recommend that in the future more attention is paid to
documenting publicly that someone's being booted out was
inevitable, by an exchange of messages on python-dev (or
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
Usual disclaimer: I am not a python-dev, just a lurker who sticks his 2c in
sometimes...
On 22Sep2010 07:17, Guido van Rossum gu...@python.org wrote:
| On Wed, Sep 22, 2010 at 4:07 AM, Nick Coghlan ncogh...@gmail.com wrote:
| On Wed, Sep 22, 2010 at 8:47 PM, Antoine Pitrou solip...@pitrou.net
On 22/09/2010 16:44, Guido van Rossum wrote:
On Wed, Sep 22, 2010 at 8:29 AM, Stephen J. Turnbullstep...@xemacs.org wrote:
Guido van Rossum writes:
I would recommend that in the future more attention is paid to
documenting publicly that someone's being booted out was
inevitable,
On 9/22/2010 6:47 AM, Antoine Pitrou wrote:
There was a whole python-dev thread some time (weeks? months?) ago where
several of us already tried to suggest more fruitful ways of
contributing, suggestions which weren't received very welcomingly AFAIR.
There were two types of criticisms and
Yikes - Mark has done terrific work in some very demanding areas,
I'd hate to see him feel unwelcome. So that's my advice: find a way
to smooth this over. You're welcome ;-)
[Guido]
...
I understand the desire to keep dirty laundry in. I would like to keep
it in too. Unfortunately the
On Wed, Sep 22, 2010 at 5:18 PM, Tim Peters tim.pet...@gmail.com wrote:
Yikes - Mark has done terrific work in some very demanding areas,
I'd hate to see him feel unwelcome. So that's my advice: find a way
to smooth this over. You're welcome ;-)
[Guido]
...
I understand the desire to
On Wed, 22 Sep 2010 19:18:35 -0400, Terry Reedy tjre...@udel.edu wrote:
On 9/22/2010 6:47 AM, Antoine Pitrou wrote:
Now I understand that opinions over this may vary and involve multiple
factors, but I would suggest that at least a bit of mentoring is needed
if we want to give privileges
On 9/22/2010 8:31 PM, Guido van Rossum wrote:
[...]
Which to me sounds defiant and passive-aggressive. I don't
want to go into analyzing, but I expect that Mark has issues
that are beyond what this community can deal with.
Even I felt a bit offended by that one ;-)
That was
On Wed, Sep 22, 2010 at 18:24, R. David Murray rdmur...@bitdance.com wrote:
On Wed, 22 Sep 2010 19:18:35 -0400, Terry Reedy tjre...@udel.edu wrote:
On 9/22/2010 6:47 AM, Antoine Pitrou wrote:
Now I understand that opinions over this may vary and involve multiple
factors, but I would suggest
On Thu, 23 Sep 2010 10:18:39 am Tim Peters wrote:
Yikes - Mark has done terrific work in some very demanding areas,
I'd hate to see him feel unwelcome. So that's my advice: find a
way to smooth this over. You're welcome ;-)
I'd like to second that. Mark has been pushy, annoying and
Cameron Simpson writes:
I've just read that thread. Mark doesn't sound that way to me. I
disagree entirely is an entirely valid response, when backed up
with argument, such as his immediately following sentence:
Perhaps we should simply agree to disagree,
Agreeing to disagree *on
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 breamore...@yahoo.co.uk wrote:
I'm rather sad to have been sacked, but such is life. I won't be doing any
more work on the bug tracker for obvious reasons, but hope that you who have
managed to keep your voluntary jobs manage to keep Python going.
68 matches
Mail list logo
