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 (bu
On Sat, Sep 25, 2010 at 1:12 AM, Antoine Pitrou 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 proble
> 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
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
É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
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 the
> > 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 chan
On Sat, Sep 25, 2010 at 12: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 thos
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 wel
On Sat, Sep 25, 2010 at 12:31 AM, Antoine Pitrou wrote:
>
>> > But we also have "performance", "crash", "resource usage"... Are we
>> > suggesting we devise a separate list box for each of these issue types?
>>
>> I must admit, I've never actually found much use for those additional
>> options. If
> > 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",
>
On Fri, Sep 24, 2010 at 10:26 PM, Antoine Pitrou wrote:
> On Fri, 24 Sep 2010 11:07:59 +0200
> Éric Araujo 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)
>> () Securit
On Fri, 24 Sep 2010 11:07:59 +0200
Éric Araujo wrote:
> How about revamping the type/versions fields?
>
> Issue type
> () Feature request (blocked by moratorium: () yes () no)
> () Bug (found in: [] 2.7 [] 3.1 [] py3k)
> () Security bug (found in: [] 2.5 [] 2.6 [] 2.7 [] 3.1 [] py3k)
>
> I’m get
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 ag
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 a
"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
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 i
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
relea
On 9/23/2010 6:17 PM, Nick Coghlan wrote:
On Fri, Sep 24, 2010 at 5:50 AM, Georg Brandl 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 Versi
On Fri, Sep 24, 2010 at 3:44 AM, 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 assi
On Fri, Sep 24, 2010 at 5:50 AM, Georg Brandl wrote:
>> Setting Versions properly helps anyone searching for issues relevant to
>> a particular version. If having a field set properly does not matter,
>> then is should not be there. Are you suggesting that Versions be deleted?
>
> ISTM that the "v
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 di
>> 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
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 i
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 b
On Thu, 23 Sep 2010 11:50:26 -0600, "Zooko O'Whielacronx"
wrote:
> Also, I would like to point out that, not having read the other
> traffic that this thread alludes to, either from earlier mailing list
> threads or from IRC, I don't really understand what exactly Mark did
> wrong. The complaints
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
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 contribution
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
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 o
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
>>> 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
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 keyword
> 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 t
On 23/09/2010 10:59, Antoine Pitrou wrote:
On Thu, 23 Sep 2010 13:32:07 +0900
"Stephen J. Turnbull" 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,
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,
>>
On Wed, 22 Sep 2010 21:24:49 -0400
"R. David Murray" wrote:
>
> > deputed tracker authority/ies. Not everyone has the same idea about how
> > to handle the various fields and processes. Who decides in cases of
> > disagreement?
>
> We discussed this a while back and I don't think we really hav
On Thu, 23 Sep 2010 13:32:07 +0900
"Stephen J. Turnbull" wrote:
>
> Triaging and closing bug reports are
> not the only functions of the tracker, and in fact they are subsidiary
> to actual bug-fixing work.
+1. What we really need is people analyzing issues, posting patches or
reviewing existing
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 anyw
> 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 yo
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
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
>>
>> 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 jus
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
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 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 dema
On Wed, Sep 22, 2010 at 18:24, R. David Murray wrote:
> On Wed, 22 Sep 2010 19:18:35 -0400, Terry Reedy 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 mento
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 on
On Wed, 22 Sep 2010 19:18:35 -0400, Terry Reedy wrote:
> On 9/22/2010 6:47 AM, Antoine Pitrou wrote:
> > Now I understand that opinions over this may vary and involve multiple
> > factors, but I would suggest that at least a bit of mentoring is needed
> > if we want to give privileges early on.
>
On Wed, Sep 22, 2010 at 5:18 PM, 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 ;-)
>
> [Guido]
>>> ...
>>> I understand the desire to keep dirty
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 th
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 sug
On 22/09/2010 16:44, Guido van Rossum wrote:
On Wed, Sep 22, 2010 at 8:29 AM, Stephen J. Turnbull 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
Usual disclaimer: I am not a python-dev, just a lurker who sticks his 2c in
sometimes...
On 22Sep2010 07:17, Guido van Rossum wrote:
| On Wed, Sep 22, 2010 at 4:07 AM, Nick Coghlan wrote:
| > On Wed, Sep 22, 2010 at 8:47 PM, Antoine Pitrou wrote:
| >> Simply, situations like the above (Mark clo
> 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 py
On Wed, Sep 22, 2010 at 8:29 AM, Stephen J. Turnbull wrote:
> Guido van Rossum writes:
>
> > I would recommend that in the future more attention is paid to
> > "documenting" publicly that someone's being booted out was
> > inevitable, by an exchange of messages on python-dev (or
> > python-com
On Thu, 23 Sep 2010 00:29:23 +0900
"Stephen J. Turnbull" 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
> > pytho
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 tha
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 leve
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 t
2010/9/22 Guido van Rossum :
> On Wed, Sep 22, 2010 at 4:07 AM, Nick Coghlan wrote:
>> A number of lingering issues that would have otherwise continued
>> lingering did indeed get closed. That work is still appreciated, even
>> if it was ultimately deemed by the other tracker admins not to be
>> s
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 wrote:
>> On Wed, Sep 22, 2010 at 8:47 PM, Antoine Pitrou
>> wrote:
>>> Simply, situations like the above (Mark closing a bug just because
>>> nobo
On Wed, Sep 22, 2010 at 4:07 AM, Nick Coghlan wrote:
> On Wed, Sep 22, 2010 at 8:47 PM, Antoine Pitrou 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, obvio
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 8:47 PM, Antoine Pitrou 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 t
On Tue, 21 Sep 2010 20:16:52 -0400
Jack Diederich wrote:
> On Tue, Sep 21, 2010 at 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
On Tue, Sep 21, 2010 at 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.
Umm, what? You mea
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.
___
68 matches
Mail list logo
