Mailman 3 Small RFEs and the Bug Tracker - Python-Dev

Small RFEs and the Bug Tracker

Facundo Batista

18 Feb 2008 18 Feb '08

7:22 p.m.

Hi! Don't now if always, or in the last few months where I've been following the issues more closely, but I found that are appearing a lot of small RFEs in the tracker. These normally are small but not trivial things. In most cases when I read them I think "Mmm, yes... it won't hurt to have it, but it's not so important, and definitively not my itch to scratch". See, for example, this [1] one, that ask for a factorial method in the integers. Normally these RFEs stay there for a long time, unless they're clearly negative, because they don't raise any discussion. OTOH, we have a PEP for feature requests [2]. I quote part of it: """ This PEP was created to allow us to close bug reports that are really feature requests. Marked as Open, they distract from the list of real bugs (which should ideally be less than a page). Marked as Closed, they tend to be forgotten. The procedure now is: if a bug report is really a feature request, add the feature request to this PEP; mark the bug as "feature request", "later", and "closed"; and add a comment to the bug saying that this is the case (mentioning the PEP explicitly). """ This is still valid? Should we start moving RFEs to this PEP and closing their issues in the tracker? Or should we try to get more discussion regarding these RFEs? Maybe, for example, a weekly digest where the latests RFEs added are sent to python-dev, so we can actually say "no way" and close them, or say "nice" and *then* moving them to the PEP (this has the risk of nobody saying anything, and to stay in the same position as before). What do you think? Opinions? Thank you very much! Regards, [1] http://bugs.python.org/issue2138 [2] http://www.python.org/dev/peps/pep-0042/ -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/

Show replies by date

Virgil Dupras

18 Feb 18 Feb

8:38 p.m.

On 2/18/08, Facundo Batista wrote:

...

Hi!

Don't now if always, or in the last few months where I've been following the issues more closely, but I found that are appearing a lot of small RFEs in the tracker.

These normally are small but not trivial things. In most cases when I read them I think "Mmm, yes... it won't hurt to have it, but it's not so important, and definitively not my itch to scratch". See, for example, this [1] one, that ask for a factorial method in the integers.

Normally these RFEs stay there for a long time, unless they're clearly negative, because they don't raise any discussion.

OTOH, we have a PEP for feature requests [2]. I quote part of it:

""" This PEP was created to allow us to close bug reports that are really feature requests. Marked as Open, they distract from the list of real bugs (which should ideally be less than a page). Marked as Closed, they tend to be forgotten. The procedure now is: if a bug report is really a feature request, add the feature request to this PEP; mark the bug as "feature request", "later", and "closed"; and add a comment to the bug saying that this is the case (mentioning the PEP explicitly). """

This is still valid? Should we start moving RFEs to this PEP and closing their issues in the tracker?

Or should we try to get more discussion regarding these RFEs? Maybe, for example, a weekly digest where the latests RFEs added are sent to python-dev, so we can actually say "no way" and close them, or say "nice" and *then* moving them to the PEP (this has the risk of nobody saying anything, and to stay in the same position as before).

What do you think? Opinions?

Thank you very much!

Regards,

[1] http://bugs.python.org/issue2138 [2] http://www.python.org/dev/peps/pep-0042/

-- . Facundo

Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/hsoft%40hardcoded.net

Personally, I think that a bug tracker is a good place to keep RFE, not a PEP. I think that the PEP would tend to be cluttered with RFE nobody cares about forever. So the clutter can never be cleaned unless someone takes the responsibility to mercilessly remove them. What I really think should be done is first to get rid of all these 8+ months old issues, and then have a kind of system that after 8 months, an issue goes back in "dying mode" where it surfaces back with a message "Does anyone have any reason to believe this issue should still be alive?" If there is no answer after a week, the issue is closed. -- Virgil

Jeroen Ruigrok van der Werven

19 Feb 19 Feb

2:21 a.m.

-On [20080218 13:38], Virgil Dupras (hsoft@hardcoded.net) wrote:

...

Personally, I think that a bug tracker is a good place to keep RFE, not a PEP. I think that the PEP would tend to be cluttered with RFE nobody cares about forever. So the clutter can never be cleaned unless someone takes the responsibility to mercilessly remove them.

A bug tracker is a much better way of registering such information. It also can be easier referenced in the future since even though when it is closed, the debate and other stuff will remain in the tracker's tickets for posterity. :) PEP: -1 tracker: +1 -- Jeroen Ruigrok van der Werven / asmodai イェルーンラウフロックヴァンデルウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ But Time, keeps flowing like a river (on and on)...

Amaury Forgeot d'Arc

3:11 a.m.

Jeroen Ruigrok van der Werven wrote:

...

-On [20080218 13:38], Virgil Dupras (hsoft@hardcoded.net) wrote:

...
Personally, I think that a bug tracker is a good place to keep RFE, not a PEP. I think that the PEP would tend to be cluttered with RFE nobody cares about forever. So the clutter can never be cleaned unless someone takes the responsibility to mercilessly remove them.

A bug tracker is a much better way of registering such information. It also can be easier referenced in the future since even though when it is closed, the debate and other stuff will remain in the tracker's tickets for posterity. :)

PEP: -1 tracker: +1

I agree. Then we can set some status/keyword when the subject of a RFE is accepted by core developers, saying "if someone proposes a patch, it has a chance to be reviewed and applied". It may incite occasional contributors to work on some of these tasks, confident that their work will not be thrown away in two seconds. -- Amaury Forgeot d'Arc

Brett Cannon

4:41 a.m.

On Feb 18, 2008 11:11 AM, Amaury Forgeot d'Arc wrote:

...

Jeroen Ruigrok van der Werven wrote:

...
-On [20080218 13:38], Virgil Dupras (hsoft@hardcoded.net) wrote:

...
Personally, I think that a bug tracker is a good place to keep RFE, not a PEP. I think that the PEP would tend to be cluttered with RFE nobody cares about forever. So the clutter can never be cleaned unless someone takes the responsibility to mercilessly remove them.

A bug tracker is a much better way of registering such information. It also can be easier referenced in the future since even though when it is closed, the debate and other stuff will remain in the tracker's tickets for posterity. :)

PEP: -1 tracker: +1

I agree. Then we can set some status/keyword when the subject of a RFE is accepted by core developers, saying "if someone proposes a patch, it has a chance to be reviewed and applied". It may incite occasional contributors to work on some of these tasks, confident that their work will not be thrown away in two seconds.

My issue with keeping the RFEs in the tracker as they are is that it artificially inflates the open issue count. Python does not have over 1,700 open bugs. So I have no issue with keeping the RFEs in the tracker, at some point I do want to change how they are represnted so that they are a separate things from issues representing bugs and patches. -Brett

Virgil Dupras

4:47 a.m.

On 2/18/08, Brett Cannon wrote:

...

On Feb 18, 2008 11:11 AM, Amaury Forgeot d'Arc wrote:

...
Jeroen Ruigrok van der Werven wrote:

...
-On [20080218 13:38], Virgil Dupras (hsoft@hardcoded.net) wrote:

...
Personally, I think that a bug tracker is a good place to keep RFE, not a PEP. I think that the PEP would tend to be cluttered with RFE nobody cares about forever. So the clutter can never be cleaned unless someone takes the responsibility to mercilessly remove them.

A bug tracker is a much better way of registering such information. It also can be easier referenced in the future since even though when it is closed, the debate and other stuff will remain in the tracker's tickets for posterity. :)

PEP: -1 tracker: +1

I agree. Then we can set some status/keyword when the subject of a RFE is accepted by core developers, saying "if someone proposes a patch, it has a chance to be reviewed and applied". It may incite occasional contributors to work on some of these tasks, confident that their work will not be thrown away in two seconds.

My issue with keeping the RFEs in the tracker as they are is that it artificially inflates the open issue count. Python does not have over 1,700 open bugs.

So I have no issue with keeping the RFEs in the tracker, at some point I do want to change how they are represnted so that they are a separate things from issues representing bugs and patches.

-Brett

Which is why I propose to have a mechanism to close bugs and RFE nobody cares about. over *1000* out of those 1700 open issues are 6+ months old. Virgil

Steve Holden

5:15 a.m.

Virgil Dupras wrote:

...

On 2/18/08, Brett Cannon wrote: [...]

...
So I have no issue with keeping the RFEs in the tracker, at some point I do want to change how they are represnted so that they are a separate things from issues representing bugs and patches.

-Brett

Which is why I propose to have a mechanism to close bugs and RFE nobody cares about. over *1000* out of those 1700 open issues are 6+ months old.

I'm not sure we should be throwing RFE's away with such casual abandon just because nobody had time to pay them any attention in six months - nor bugs neither, come to that. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/

Gregory P. Smith

5:22 a.m.

...

...
Which is why I propose to have a mechanism to close bugs and RFE nobody cares about. over *1000* out of those 1700 open issues are 6+ months old.

I'm not sure we should be throwing RFE's away with such casual abandon just because nobody had time to pay them any attention in six months - nor bugs neither, come to that.

Virgil Dupras

5:29 a.m.

On 2/18/08, Steve Holden wrote:

...

I'm not sure we should be throwing RFE's away with such casual abandon just because nobody had time to pay them any attention in six months - nor bugs neither, come to that.

Well, we have to evaluate the chances of our older tickets to come to completion. I'm of the opinion that ticket getting older have very small chances of ever being completed. RFE for python 2.4 are likely to be irrelevant. old bugs are likely to already be fixed. Maybe we could run a statistical analysis to compute the chances of a ticket that have seen no activity for 8 months to ever be successfully completed? How many successful tickets to we have that had a 8+ months gap between activity? Or maybe we could just clean out the 400 tickets that are 2+ years old? What are the chances for a 2 years old ticket to be completed? -- Virgil

Steve Holden

5:36 a.m.

Virgil Dupras wrote:

...

On 2/18/08, Steve Holden wrote:

...
I'm not sure we should be throwing RFE's away with such casual abandon just because nobody had time to pay them any attention in six months - nor bugs neither, come to that.

Well, we have to evaluate the chances of our older tickets to come to completion. I'm of the opinion that ticket getting older have very small chances of ever being completed. RFE for python 2.4 are likely to be irrelevant. old bugs are likely to already be fixed. Maybe we could run a statistical analysis to compute the chances of a ticket that have seen no activity for 8 months to ever be successfully completed? How many successful tickets to we have that had a 8+ months gap between activity? Or maybe we could just clean out the 400 tickets that are 2+ years old? What are the chances for a 2 years old ticket to be completed?

But the decision shouldn't be made on the age of the ticket, rather on the (continued?) validity of the information it contains. I appreciate the desire to "keep the issue tracker clean", but I think human intelligence needs to be applied to the task, not just a date-based cutoff. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/

Virgil Dupras

5:48 a.m.

On 2/18/08, Steve Holden wrote:

...

I appreciate the desire to "keep the issue tracker clean", but I think human intelligence needs to be applied to the task, not just a date-based cutoff.

Personally, the bug count doesn't bother me. I was just responding to Brett's concerns about the high issue count, saying that having the issue tracker keep track of the RFE is not what makes that count so high. I'm ok with the status quo. Virgil

Raymond Hettinger

5:56 a.m.

[Steve Holden]

...

I appreciate the desire to "keep the issue tracker clean", but I think human intelligence needs to be applied to the task, not just a date-based cutoff.

I concur. The older bug reports are ones that have survived past human-based clean-up efforts. They were left open as a reminder, as a todo, to await time or decision by a module author, or it wasn't clear how to solve valid report. IIRC, there are some for regexes that would take the time of the one or two people supporting that module and the request would cover a not urgently needed corner cases (like handling empty matches or speeding-up badly designed regexes). Those bug reports and rfes are valid and should be left open unless a module author decides that re's won't support the request. Raymond

"Martin v. Löwis"

8 a.m.

...

Well, we have to evaluate the chances of our older tickets to come to completion. I'm of the opinion that ticket getting older have very small chances of ever being completed. RFE for python 2.4 are likely to be irrelevant.

Do you have any facts to base this theory on? Two years for a bug report is *nothing*. Ten years, and I would start to worry that it might never get implemented. Regards, Martin

Virgil Dupras

3:52 p.m.

On 2/19/08, "Martin v. Löwis" wrote:

...

...
Well, we have to evaluate the chances of our older tickets to come to completion. I'm of the opinion that ticket getting older have very small chances of ever being completed. RFE for python 2.4 are likely to be irrelevant.

Do you have any facts to base this theory on?

Two years for a bug report is *nothing*. Ten years, and I would start to worry that it might never get implemented.

No, I don't, which is why I would find it interesting to run some queries on the roundup database to have completion statistics for low activity tickets. Is is possible to get a copy of that db somehow? Virgil

"Martin v. Löwis"

4 p.m.

...

No, I don't, which is why I would find it interesting to run some queries on the roundup database to have completion statistics for low activity tickets. Is is possible to get a copy of that db somehow?

I would rather not make it available, as it contains certain privacy-related information that we need to withhold. If you provide some SQL statement or Python script that you want me to run on the server - that should be possible. Regards, Martin

Virgil Dupras

5:42 p.m.

On 2/19/08, "Martin v. Löwis" wrote:

...

...
No, I don't, which is why I would find it interesting to run some queries on the roundup database to have completion statistics for low activity tickets. Is is possible to get a copy of that db somehow?

I would rather not make it available, as it contains certain privacy-related information that we need to withhold. If you provide some SQL statement or Python script that you want me to run on the server - that should be possible.

Hum, Roundup has a rather nice little API to it's issues. Here we go. It would be nice to have stats for 360 days as well. #!/usr/bin/env python # I'm building this out of a demo db of roundup, and it doesn't have a "Resolution", so # I'm doing guesswork here. It shouldn't be very hard to modify the script to fit the # python db. PATH_TO_TRACKER = 'demo' ACTIVITY_DAY_THRESHOLD = 180 import roundup.instance def has_large_activity_gap(issue, db): for first, second in zip(issue.messages, issue.messages[1:]): date1 = db.msg.getnode(first).date date2 = db.msg.getnode(second).date if date2.differenceDate(date1).as_seconds() >= ACTIVITY_DAY_THRESHOLD * 3600: return True return False tracker = roundup.instance.Tracker(PATH_TO_TRACKER) db = tracker.open() closed_status = db.status.lookup('chatting') resolution2count = {} for resolution_id in db.resolution.getnodeids(): resolution2count[resolution_id] = 0 closed_issues = (db.issue.getnode(issue_id) for issue_id in db.issue.find(status=closed_status)) low_activity_issues = (issue for issue in closed_issues if has_large_activity_gap(issue, db)) for issue in low_activity_issues: resolution2count[issue.resolution] += 1 print 'Low activity tickets (%d days) broken down per resolution status:' % ACTIVITY_DAY_THRESHOLD print for resolution_id, count in resolution2count.items(): resolution = db.resolution.getnode(resolution_id) print '%s\t%d' % (resolution.name, count)

Virgil Dupras

5:44 p.m.

On 2/19/08, Virgil Dupras wrote:

...

closed_status = db.status.lookup('chatting')

Oops, replace 'chatting' with 'closed' Virgil

"Martin v. Löwis"

21 Feb 21 Feb

7:48 a.m.

Virgil Dupras wrote:

...

On 2/19/08, Virgil Dupras wrote:

...
closed_status = db.status.lookup('chatting')

Oops, replace 'chatting' with 'closed'

Ok, I ran the script. It said Low activity tickets (180 days) broken down per resolution status: - no selection - 547 wont fix 423 works for me 194 accepted 1233 fixed 2257 duplicate 176 later 49 invalid 275 postponed 20 out of date 304 remind 5 rejected 448 Attached is the updated script. Notice that a day has more than 3600 seconds. With if date2.differenceDate(date1).as_seconds() >= ACTIVITY_DAY_THRESHOLD * 24 * 3600 it gives - no selection - 118 wont fix 189 works for me 62 accepted 310 fixed 611 duplicate 75 later 17 invalid 73 postponed 6 out of date 193 remind 1 rejected 180 Regards, Martin

Virgil Dupras

3:59 p.m.

On 2/21/08, "Martin v. Löwis" wrote:

...

- no selection - 118 wont fix 189 works for me 62 accepted 310 fixed 611 duplicate 75 later 17 invalid 73 postponed 6 out of date 193 remind 1 rejected 180

Thanks for running it. The rate is better than I expected, so I was wrong in my assumption. What would be the difference between accepted and fixed for a closed ticket? Virgil

Guido van Rossum

11:31 p.m.

On Wed, Feb 20, 2008 at 11:59 PM, Virgil Dupras wrote:

...

On 2/21/08, "Martin v. Löwis" wrote:

...
- no selection - 118 wont fix 189 works for me 62 accepted 310 fixed 611 duplicate 75 later 17 invalid 73 postponed 6 out of date 193 remind 1 rejected 180

Thanks for running it. The rate is better than I expected, so I was wrong in my assumption.

What would be the difference between accepted and fixed for a closed ticket?

I don't know what others do, but I use accepted for a patch submission and fixed for a bug report. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

Steve Holden

11:50 p.m.

Guido van Rossum wrote:

...

On Wed, Feb 20, 2008 at 11:59 PM, Virgil Dupras wrote:

...
On 2/21/08, "Martin v. Löwis" wrote:

...
- no selection - 118 wont fix 189 works for me 62 accepted 310 fixed 611 duplicate 75 later 17 invalid 73 postponed 6 out of date 193 remind 1 rejected 180

Thanks for running it. The rate is better than I expected, so I was wrong in my assumption.

What would be the difference between accepted and fixed for a closed ticket?

I don't know what others do, but I use accepted for a patch submission and fixed for a bug report.

That sounds eminently sensible. So sensible there should be documentation that tells us to do that. Drat it, where's Brett Cannon when you need him? :-) regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/

Gregory P. Smith

11:59 p.m.

On 2/21/08, Steve Holden wrote:

...

Guido van Rossum wrote:

...
On Wed, Feb 20, 2008 at 11:59 PM, Virgil Dupras wrote:

...
...
What would be the difference between accepted and fixed for a closed ticket?

I don't know what others do, but I use accepted for a patch submission and fixed for a bug report.

That sounds eminently sensible. So sensible there should be documentation that tells us to do that. Drat it, where's Brett Cannon when you need him? :-)

I'm always faced with a tiny quandry when closing a fixed bug that had a patch to fix it attached because both seem to apply. ;-)

Facundo Batista

22 Feb 22 Feb

12:06 a.m.

2008/2/21, Gregory P. Smith :

...

...
That sounds eminently sensible. So sensible there should be documentation that tells us to do that. Drat it, where's Brett Cannon when you need him? :-)

I'm always faced with a tiny quandry when closing a fixed bug that had a patch to fix it attached because both seem to apply. ;-)

Yeap, and I'm sure I ave a % of wrongly marked issues when closing, :p. Anyway, if a patch, and a bug, and a RFE, etc, are all "issues", IMHO is cluttering the fact that we have two or three denominations to "this issue was ok and we executed the proper actions to close it". Everything in this aspect would be simpler if we have one word for what I just meant. Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/

"Martin v. Löwis"

3:55 a.m.

...

Everything in this aspect would be simpler if we have one word for what I just meant.

If you think it should be fixed, please submit a report in the meta tracker, ideally specifying precisely how you want to see it changed. It's possible to "retire" objects in Roundup: certain resolution values would still be present and referenced by issues that use it, but they would not appear anymore in the drop-down list. Regards, Martin

Facundo Batista

7:34 p.m.

2008/2/21, "Martin v. Löwis" :

...

It's possible to "retire" objects in Roundup: certain resolution values would still be present and referenced by issues that use it, but they would not appear anymore in the drop-down list.

We can go one step further: If we change "fixed" and "accepted" as "resolved" (for example), we can change all the values directly in the database, so they all appear as "resolved" now. I don't want to propose anything specific regarding words, I'm just saying that having eleven options to close an issue are too many if we want to keep consistency. Note that they're not clear enough to make them obvious, otherwise the consensus in this thread would have been faster, ;) Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/

"Martin v. Löwis"

23 Feb 23 Feb

1:53 a.m.

...

We can go one step further: If we change "fixed" and "accepted" as "resolved" (for example), we can change all the values directly in the database, so they all appear as "resolved" now.

I don't want to propose anything specific regarding words, I'm just saying that having eleven options to close an issue are too many if we want to keep consistency.

I'd like to point out that there is only one way to close an issue: set it to "closed" state. What you (and everybody else) here is talking about the resolution (i.e. an indication how the issue was resolved). If you propose that there is only one possible resolution, namely "resolved", then wouldn't it be best to remove the resolution entirely?

...

Note that they're not clear enough to make them obvious, otherwise the consensus in this thread would have been faster, ;)

Right. I wish this discussion had taken place before the tracker switchover. Regards, Martin

Brett Cannon

22 Feb 22 Feb

5:24 a.m.

On Thu, Feb 21, 2008 at 8:06 AM, Facundo Batista wrote:

...

2008/2/21, Gregory P. Smith :

...
...
That sounds eminently sensible. So sensible there should be documentation that tells us to do that. Drat it, where's Brett Cannon when you need him? :-)

I'm always faced with a tiny quandry when closing a fixed bug that had a patch to fix it attached because both seem to apply. ;-)

Yeap, and I'm sure I ave a % of wrongly marked issues when closing, :p.

Anyway, if a patch, and a bug, and a RFE, etc, are all "issues", IMHO is cluttering the fact that we have two or three denominations to "this issue was ok and we executed the proper actions to close it".

Everything in this aspect would be simpler if we have one word for what I just meant.

Something like "handle" or "resolved". An issue is an issue and we wanting a single way to say the issue was closed because what is was about was handled seems reasonable. -Brett

Facundo Batista

7:29 p.m.

2008/2/21, Brett Cannon :

...

Something like "handle" or "resolved". An issue is an issue and we wanting a single way to say the issue was closed because what is was about was handled seems reasonable.

+1 to resolved. -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/

Nick Coghlan

6:36 p.m.

Gregory P. Smith wrote:

...

I'm always faced with a tiny quandry when closing a fixed bug that had a patch to fix it attached because both seem to apply. ;-)

I try to use 'fixed' for those, with my closure comment indicating whether the fix used the attached patch (or a variant thereof) or something completely different. Combining 'fixed' and 'accepted' into something generic like 'resolved' is no good, since 'not a bug' is also a resolution from our point of view, even if the original author of the issue may not particularly like the answer :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org

Facundo Batista

7:31 p.m.

2008/2/22, Nick Coghlan :

...

Combining 'fixed' and 'accepted' into something generic like 'resolved' is no good, since 'not a bug' is also a resolution from our point of view, even if the original author of the issue may not particularly like the answer :)

First two definitions of "resolve" from the American Heritage dict: 1. To make a firm decision about. 2. To cause (a person) to reach a decision. I think it applies quite well. Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/

Nick Coghlan

7:57 p.m.

Facundo Batista wrote:

...

First two definitions of "resolve" from the American Heritage dict:

1. To make a firm decision about. 2. To cause (a person) to reach a decision.

I think it applies quite well.

It only tells you that a resolution was reached, not what that resolution was. "Resolution: resolved" is meaningless repetition - what matters is *how* the issue was resolved, and simply saying 'resolved' doesn't tell anybody that. 'Fixed', 'accepted', 'invalid', 'rejected' , etc are resolutions since they give you some idea of how the issue was resolved - the only thing missing is a definition of just how they should be used.* Now, dropping 'later', 'postponed' and 'remind' from the list of available resolutions is something I could wholeheartedly support. If we want to postpone something to a later release, we should put an appropriate entry in the version list. My stab at definitions for the other resolutions: # Feature request resolutions accepted - feature request accepted (possibly via attached patch) rejected - feature request rejected # Bug report resolutions fixed - reported bug fixed (possibly via attached patch) invalid - reported behaviour is intentional and not a bug works for me - bug could not be replicated from bug report out of date - bug is already fixed in later Python version wont fix - valid bug, but not fixable in CPython (very rare) # Common resolutions duplicate - same as another issue (refer to other issue in a comment) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org

Facundo Batista

8:28 p.m.

2008/2/22, Nick Coghlan :

...

Now, dropping 'later', 'postponed' and 'remind' from the list of available resolutions is something I could wholeheartedly support. If we want to postpone something to a later release, we should put an appropriate entry in the version list.

My stab at definitions for the other resolutions:

# Feature request resolutions accepted - feature request accepted (possibly via attached patch) rejected - feature request rejected

# Bug report resolutions fixed - reported bug fixed (possibly via attached patch) invalid - reported behaviour is intentional and not a bug works for me - bug could not be replicated from bug report out of date - bug is already fixed in later Python version wont fix - valid bug, but not fixable in CPython (very rare)

# Common resolutions duplicate - same as another issue (refer to other issue in a comment)

Fair enough. There's missing one use case: how we mark an issue that is not such? I'm talking about issues opened without an explanation, nothing saying what is wrong, or which behaviour is strange or wrong for the original poster, etc. Those issues that you want to answer "go back and learn how to explain yourself". Thanks! -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/

Georg Brandl

23 Feb 23 Feb

12:05 a.m.

Nick Coghlan schrieb:

...

Facundo Batista wrote:

...
First two definitions of "resolve" from the American Heritage dict:

1. To make a firm decision about. 2. To cause (a person) to reach a decision.

I think it applies quite well.

It only tells you that a resolution was reached, not what that resolution was.

"Resolution: resolved" is meaningless repetition - what matters is *how* the issue was resolved, and simply saying 'resolved' doesn't tell anybody that. 'Fixed', 'accepted', 'invalid', 'rejected' , etc are resolutions since they give you some idea of how the issue was resolved - the only thing missing is a definition of just how they should be used.*

Now, dropping 'later', 'postponed' and 'remind' from the list of available resolutions is something I could wholeheartedly support. If we want to postpone something to a later release, we should put an appropriate entry in the version list.

+1 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.

Adam Olsen

1:16 a.m.

On Fri, Feb 22, 2008 at 4:57 AM, Nick Coghlan wrote:

...

# Feature request resolutions accepted - feature request accepted (possibly via attached patch) rejected - feature request rejected

Can we make the names a little longer? "feature accepted" and "feature rejected" are more obvious than simply "accepted" and "rejected". Same for some of the bug ones.

...

# Bug report resolutions fixed - reported bug fixed (possibly via attached patch) invalid - reported behaviour is intentional and not a bug works for me - bug could not be replicated from bug report out of date - bug is already fixed in later Python version wont fix - valid bug, but not fixable in CPython (very rare)

# Common resolutions duplicate - same as another issue (refer to other issue in a comment)

-- Adam Olsen, aka Rhamphoryncus

"Martin v. Löwis"

2:01 a.m.

...

Can we make the names a little longer?

Somebody really needs to take lead here. I won't change anything unless somebody tells me precisely what to do, so I can blame somebody. Messages like this (which I picked just arbitrarily) I will ignore wrt. specific action. Of course I *can* make the names a little longer - it's a thirty-second edit. The question is whether I should. Again, taking your message just arbitrarily. The same remark applies to anything else declared as a proposal - I can only act on specifications, not on proposals. Regards, Martin

Brett Cannon

5:06 a.m.

On Fri, Feb 22, 2008 at 10:01 AM, "Martin v. Löwis" wrote:

...

...
Can we make the names a little longer?

Somebody really needs to take lead here. I won't change anything unless somebody tells me precisely what to do, so I can blame somebody. Messages like this (which I picked just arbitrarily) I will ignore wrt. specific action. Of course I *can* make the names a little longer - it's a thirty-second edit. The question is whether I should.

Again, taking your message just arbitrarily. The same remark applies to anything else declared as a proposal - I can only act on specifications, not on proposals.

I think Martin is right that someone needs to take the lead and do a complete review of how issues are handled. That way we can do a change in one big batch to something that works better for Python. I have always planned to take the lead on this, but it will have to wait until probably Python 3.0 is out the door. If someone else wants to go through and really look at how we handle issues and propose a new schema that's fine by me. -Brett

Facundo Batista

5:21 a.m.

2008/2/22, Brett Cannon :

...

I think Martin is right that someone needs to take the lead and do a complete review of how issues are handled. That way we can do a change in one big batch to something that works better for Python.

+1 What about a couple of hours in the Python Core sprinting in a month? I won't be there (in that specific sprint), but I trust your decision. Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/

Brett Cannon

5:29 a.m.

On Fri, Feb 22, 2008 at 1:21 PM, Facundo Batista wrote:

...

2008/2/22, Brett Cannon :

...
I think Martin is right that someone needs to take the lead and do a complete review of how issues are handled. That way we can do a change in one big batch to something that works better for Python.

+1

What about a couple of hours in the Python Core sprinting in a month? I won't be there (in that specific sprint), but I trust your decision.

Maybe. Could possibly take an hour or so after a lunch and just have everyone at the sprint give feedback or something. But my personal priorities for the sprint is being a good sprint coach first, and finish getting my bootstrap of my import rewrite second. -Brett

A.M. Kuchling

5:28 a.m.

On Fri, Feb 22, 2008 at 01:06:05PM -0800, Brett Cannon wrote:

...

I think Martin is right that someone needs to take the lead and do a complete review of how issues are handled. That way we can do a change in one big batch to something that works better for Python.

Are we, as a development community, really running into problems with how we handle bugs? There are certainly small cleanups possible, such as dropping the 'postponed' and 'later' resolutions that we don't seem to use very much, but the flow seems reasonably efficient to me. I suggest just updating PEP 3 to actually describe the life cycle we currently follow. --amk

Brett Cannon

5:34 a.m.

On Fri, Feb 22, 2008 at 1:28 PM, A.M. Kuchling wrote:

...

On Fri, Feb 22, 2008 at 01:06:05PM -0800, Brett Cannon wrote:

...
I think Martin is right that someone needs to take the lead and do a complete review of how issues are handled. That way we can do a change in one big batch to something that works better for Python.

Are we, as a development community, really running into problems with how we handle bugs? There are certainly small cleanups possible, such as dropping the 'postponed' and 'later' resolutions that we don't seem to use very much, but the flow seems reasonably efficient to me.

It's reasonable, but I wonder if it could be better. I am not sure as I have not had that much time to sit down and really think it through. I do know, though, that I like how Django has it structured: http://www.djangoproject.com/documentation/contributing/#ticket-triage . -Brett

Christian Heimes

8:55 a.m.

A.M. Kuchling wrote:

...

Are we, as a development community, really running into problems with how we handle bugs? There are certainly small cleanups possible, such as dropping the 'postponed' and 'later' resolutions that we don't seem to use very much, but the flow seems reasonably efficient to me.

We have over 1,700 open issues - bug reports, feature requests and patches - in our bug tracker. In my humble opinion it's a sure sign for a problem. Christian

Guido van Rossum

9:05 a.m.

On Fri, Feb 22, 2008 at 4:55 PM, Christian Heimes wrote:

...

We have over 1,700 open issues - bug reports, feature requests and patches - in our bug tracker. In my humble opinion it's a sure sign for a problem.

I don't think so. I think it's a sign of healthy software. Now, if there were 1700 *serious* bugs, we'd have a problem. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/)

A.M. Kuchling

10:40 a.m.

On Sat, Feb 23, 2008 at 01:55:06AM +0100, Christian Heimes wrote:

...

We have over 1,700 open issues - bug reports, feature requests and patches - in our bug tracker. In my humble opinion it's a sure sign for a problem.

Sure, but is that because the bug life cycle is sub-optimal, or because we don't have enough people handling bugs? I think for a long time we haven't been actively recruiting new developers, and the pool of people with commit privileges remained about the same. Some committers go away, and some get caught up in other projects, so the number of people who actually do work is much smaller. I think that's the primary problem to solve, and the bug life cycle is much less significant. I'm not against changing the bug cycle, just doubtful that changing it will be a magic bullet for reducing the size of our backlog. --amk

"Martin v. Löwis"

3:48 p.m.

...

We have over 1,700 open issues - bug reports, feature requests and patches - in our bug tracker. In my humble opinion it's a sure sign for a problem.

As a historical record: people said the same thing when there were 500 and 1000 open issues. 5 years from now, when we have 5000 open issues, you will look back to the good old days when we were below 2000 :-) Regards, Martin

Virgil Dupras

6:07 p.m.

On 2/23/08, Christian Heimes wrote:

...

We have over 1,700 open issues - bug reports, feature requests and patches - in our bug tracker. In my humble opinion it's a sure sign for a problem.

There is also 12000 closed tickets, with 1200 of them having been closed in the last 6 months (well, having had activity in the last 6 month, but I guess that's almost equivalent). The number of issues (open or closed) that have been created in the last 6 months is about 1050. The flow seems healthy to me. Virgil

Facundo Batista

7:13 p.m.

2008/2/23, Virgil Dupras :

...

The flow seems healthy to me.

What I don't see healthy is that we have, per week, around 30 issues more open (30 is the difference between those closed, and the new ones). So, the curve is always going up... fast. -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/

Steve Holden

8:09 p.m.

Facundo Batista wrote:

...

2008/2/23, Virgil Dupras :

...
The flow seems healthy to me.

What I don't see healthy is that we have, per week, around 30 issues more open (30 is the difference between those closed, and the new ones).

So, the curve is always going up... fast.

As Andrew says, the only way to "fix" this, if you think it needs fixing, is to recruit new developers and encourage all developers to treat outstanding issues as a higher priority than they currently do. Guido is happy with the current issue count, and relatively few of them are serious. Andrew has been organizing regular bug days. If the count keeps going up that's as much a measure of the increase in use as it is anything else. I do think it would be a good idea to have a crew continually working to address the outstanding issues, but it isn't glamorous work and the fact remains that you need a significant understanding of the ecosphere to fix things in a sanitary way that's acceptable to committers. It would be good to address that issue (shoud we put it in the tracker?), but it would take significant efforts in evangelism and training. Most developers would rather just write code ... Enlarging the pool of committers too quickly probably puts quality control at risk, something I'd be loath to see happen given Python's excellent record in this respect. A larger team (not necessarily all committers) could help us improve quality and reduce the issue count. Deleting issues purely on grounds of age is simply throwing away useful information to reduce a numeric metric that doesn't really relate directly to quality, and quality assurance is the real point of having the tracker. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/

Facundo Batista

8:26 p.m.

2008/2/23, Steve Holden :

...

A larger team (not necessarily all committers) could help us improve quality and reduce the issue count. Deleting issues purely on grounds of

Exactly, that's why I love Python bug days.. and I'm pushing this hard in Argentina! In the January one, two new argentinian developers worked closing issues, and today a new one is jumping on the train. Also, we did a small bug day, in a Python Camping in Argentina, where we closed 4 or 5 issues, and two more guys learned the whole process (more on this event on other post). This evangelization is very important, IMO. -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/

Stephen J. Turnbull

24 Feb 24 Feb

7:06 a.m.

Facundo Batista writes:

...

2008/2/23, Virgil Dupras :

...

...
The flow seems healthy to me.

...

What I don't see healthy is that we have, per week, around 30 issues more open (30 is the difference between those closed, and the new ones).

So, the curve is always going up... fast.

This merely means that Python users are applying Python to problems that the current set of developers never imagined. As long as the flow of solved issues is increasing, that's a symptom of strength, not weakness. If that curve ever turns down, it means that users are giving up on Python as a tool for solving ever harder problems. That's where it gets scarey.

Facundo Batista

7:32 a.m.

2008/2/23, Stephen J. Turnbull :

...

If that curve ever turns down, it means that users are giving up on Python as a tool for solving ever harder problems. That's where it gets scarey.

It depends. If that happens because no new issues are found, maybe (it could happen also that Python gets more and more solid). But if we solve more issues than which are opened, that is good too, :) -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/

"Martin v. Löwis"

23 Feb 23 Feb

1:56 a.m.

...

First two definitions of "resolve" from the American Heritage dict:

1. To make a firm decision about. 2. To cause (a person) to reach a decision.

I think it applies quite well.

That's why the entire field is called "Resolution". "duplicate", "invalid", "out of date", "wont fix" and "works for me" are also firm decisions. ("later", "postponed", and "remind" might not be firm decisions - they were just inherited from SF). Regards, Martin

Stephen J. Turnbull

7:03 a.m.

"Martin v. Löwis" writes:

...

That's why the entire field is called "Resolution". "duplicate", "invalid", "out of date", "wont fix" and "works for me" are also firm decisions.

("later", "postponed", and "remind" might not be firm decisions - they were just inherited from SF).

These latter three are not resolutions, and IMO should be removed. Items with those "resolutions" should be considered still active (or perhaps "pending" auto-closure). Specifically, the "name" field of the corresponding items in the relevant class should be edited so that in legacy issues containing them they are displayed as "- not yet resolved -" or "- no selection -". (I'm not sure it's wise, or even possible, for multiple items to have identical names, though. If not, they can be uniquified in some way.) Then these items should be retired so that they won't appear at all in menus.

Brett Cannon

22 Feb 22 Feb

5:21 a.m.

On Thu, Feb 21, 2008 at 7:50 AM, Steve Holden wrote:

...

Guido van Rossum wrote:

...
On Wed, Feb 20, 2008 at 11:59 PM, Virgil Dupras wrote:

...
On 2/21/08, "Martin v. Löwis" wrote:

...
- no selection - 118 wont fix 189 works for me 62 accepted 310 fixed 611 duplicate 75 later 17 invalid 73 postponed 6 out of date 193 remind 1 rejected 180

Thanks for running it. The rate is better than I expected, so I was wrong in my assumption.

What would be the difference between accepted and fixed for a closed ticket?

I don't know what others do, but I use accepted for a patch submission and fixed for a bug report.

That sounds eminently sensible. So sensible there should be documentation that tells us to do that. Drat it, where's Brett Cannon when you need him? :-)

Trying to get his sprint intro talk lined up for PyCon while dealing with the stdlib reorg. =) -Brett

A.M. Kuchling

21 Feb 21 Feb

11:47 p.m.

On Thu, Feb 21, 2008 at 08:59:51AM +0100, Virgil Dupras wrote:

...

Thanks for running it. The rate is better than I expected, so I was wrong in my assumption.

What would be the difference between accepted and fixed for a closed ticket?

'accepted' is probably used more for patches, while 'fixed' is more likely to be used for a bug report. --amk

"Martin v. Löwis"

22 Feb 22 Feb

3:52 a.m.

...

What would be the difference between accepted and fixed for a closed ticket?

As Guido says: a bug gets fixed, a patch gets accepted. This was copied over from SF, but it makes sense to me and everybody seems to be following it. Regards, Martin

Facundo Batista

21 Feb 21 Feb

11:48 p.m.

2008/2/20, "Martin v. Löwis" :

...

- no selection - 118 wont fix 189 works for me 62 accepted 310 fixed 611 duplicate 75 later 17 invalid 73 postponed 6 out of date 193 remind 1 rejected 180

This is the result for the "open" status issues? I guess not, because the rejected, fixed, etc, should be closed. Could you run this again, please, but filtering by "open" tickets? Thanks! -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/

Virgil Dupras

11:53 p.m.

On 2/21/08, Facundo Batista wrote:

...

This is the result for the "open" status issues? I guess not, because the rejected, fixed, etc, should be closed.

Could you run this again, please, but filtering by "open" tickets?

I don't see why would want to run this query on open tickets. What would it tell you? How many old issue there is? You can already know that with a simple search. The goal of this script is to know the resolution of tickets that had a 6+ month gap in their activity. Virgil

Facundo Batista

11:58 p.m.

2008/2/21, Virgil Dupras :

...

I don't see why would want to run this query on open tickets. What would it tell you? How many old issue there is? You can already know that with a simple search. The goal of this script is to know the resolution of tickets that had a 6+ month gap in their activity.

In the context of what to do with RFEs (my original question), if keep them in the tracker, or removing them from there and putting them in the PEP, I want to see this distribution in the actually opened tickets (as they're disturbed or not by the RFEs). Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/

"Martin v. Löwis"

22 Feb 22 Feb

4:25 a.m.

...

This is the result for the "open" status issues? I guess not, because the rejected, fixed, etc, should be closed.

Could you run this again, please, but filtering by "open" tickets?

Here you go - no selection - 381 wont fix 2 works for me 0 accepted 4 fixed 2 duplicate 0 later 6 invalid 0 postponed 0 out of date 1 remind 0 rejected 0 As Virgil expected: it's not very meaningful, but it's what you've asked for. Regards, Martin

Jeroen Ruigrok van der Werven

19 Feb 19 Feb

4:52 a.m.

-On [20080218 21:41], Brett Cannon (brett@python.org) wrote:

...

My issue with keeping the RFEs in the tracker as they are is that it artificially inflates the open issue count. Python does not have over 1,700 open bugs.

An issue does not necessarily mean the same as bug. :) Is it a bug tracker you have or an issue tracker? If the former, agreed, if the latter then it makes sense to track RFEs in the tracker. -- Jeroen Ruigrok van der Werven / asmodai イェルーンラウフロックヴァンデルウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ And every word upon your spiralling cross is but a misled sun, a bitter loss...

Steve Holden

5:10 a.m.

Jeroen Ruigrok van der Werven wrote:

...

-On [20080218 21:41], Brett Cannon (brett@python.org) wrote:

...
My issue with keeping the RFEs in the tracker as they are is that it artificially inflates the open issue count. Python does not have over 1,700 open bugs.

An issue does not necessarily mean the same as bug. :)

Is it a bug tracker you have or an issue tracker? If the former, agreed, if the latter then it makes sense to track RFEs in the tracker.

Certainly, but since some issues *are* bugs we might need to refine our analysis somewhat. It would be better to have a bug report which omitted issues of type "rfe". As far as I can see open issues of all other types would be properly classified as bugs. There there's the Status field. I understand "open" and "closed", but what's the semantic of "pending". Is it awaiting triage, awaiting status assignment, or what? I quite like Django's "triage stage", see http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&group=stage&order=priority The stages availabele appear to be "Accepted", "Someday/Maybe", "Design decision needed", "Ready for checkin" and "Unreviewed". OK. maybe "triage" wasn't such a good name for for a four-state condition, but it serves a useful purpose and helps people understand what the ultimate fate of issues they raise might be. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/

Georg Brandl

5:39 a.m.

Steve Holden schrieb:

...

Jeroen Ruigrok van der Werven wrote:

...
-On [20080218 21:41], Brett Cannon (brett@python.org) wrote:

...
My issue with keeping the RFEs in the tracker as they are is that it artificially inflates the open issue count. Python does not have over 1,700 open bugs.

An issue does not necessarily mean the same as bug. :)

Is it a bug tracker you have or an issue tracker? If the former, agreed, if the latter then it makes sense to track RFEs in the tracker.

Certainly, but since some issues *are* bugs we might need to refine our analysis somewhat. It would be better to have a bug report which omitted issues of type "rfe". As far as I can see open issues of all other types would be properly classified as bugs.

There there's the Status field. I understand "open" and "closed", but what's the semantic of "pending". Is it awaiting triage, awaiting status assignment, or what?

It's a leftover from SF.net. There it had the feature that pending items were closed automatically after two weeks if no further activity took place. For the new tracker, we should really decide about a "pending" policy, or implement the feature too. Georg

Christian Heimes

5:28 p.m.

Steve Holden wrote:

...

There there's the Status field. I understand "open" and "closed", but what's the semantic of "pending". Is it awaiting triage, awaiting status assignment, or what?

I've used pending for two states. For one I've put an issue on pending state when it was fixed on the trunk but we haven't decided if the bugs needs to be fixed in 2.5 as well. I've also set old bugs as pending to give the op a change to reopen the bug within a month. Christian

Nick Coghlan

7:05 p.m.

Christian Heimes wrote:

...

Steve Holden wrote:

...
There there's the Status field. I understand "open" and "closed", but what's the semantic of "pending". Is it awaiting triage, awaiting status assignment, or what?

I've used pending for two states. For one I've put an issue on pending state when it was fixed on the trunk but we haven't decided if the bugs needs to be fixed in 2.5 as well. I've also set old bugs as pending to give the op a change to reopen the bug within a month.

I've used pending for the former case as well (i.e. when I wanted a verdict from the release manager on whether or not to backport a particular fix to 2.5, but didn't want the issue hanging around as open when I had already fixed it for the trunk). We really do need to write some of this down in an information track PEP so we're all using the same values to mean the same thing... Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org

"Martin v. Löwis"

20 Feb 20 Feb

6:47 a.m.

...

We really do need to write some of this down in an information track PEP so we're all using the same values to mean the same thing...

There is actually an official meaning to pending: An issue marked pending will get automatically closed by the tracker after some period of time (which used to be two weeks on SF). The tracker will add a message that the issue was closed because of inactivity. Unfortunately, that feature is not yet implemented. Regards, Martin

Gregory P. Smith

19 Feb 19 Feb

4:54 a.m.

...

...
...
PEP: -1 tracker: +1

I agree. Then we can set some status/keyword when the subject of a RFE is accepted by core developers, saying "if someone proposes a patch, it has a chance to be reviewed and applied". It may incite occasional contributors to work on some of these tasks, confident that their work will not be thrown away in two seconds.

My issue with keeping the RFEs in the tracker as they are is that it artificially inflates the open issue count. Python does not have over 1,700 open bugs.

So I have no issue with keeping the RFEs in the tracker, at some point I do want to change how they are represnted so that they are a separate things from issues representing bugs and patches.

-Brett

Sure but thats merely a tracker problem. Change your count to bugs not marked as a rfe / feature-request and you've got your real count. Tracker entries for rfes are much better than a languid document.

Nick Coghlan

7:01 p.m.

Brett Cannon wrote:

...

My issue with keeping the RFEs in the tracker as they are is that it artificially inflates the open issue count. Python does not have over 1,700 open bugs.

That's a problem with our status reporting, not with the fact that there are RFE's in the issue tracker ;) Adding a 'bug' keyword to go along with the existing 'rfe' keyword might have some merit, allowing separate stats to be reported for 'rfe', 'bug' and 'uncategorised' (neither the 'bug' nor the 'rfe' keywords have been set). It may also be interesting to separate out the documentation bugs (based on the existing category field), as while those are traps for the unwary and need to be fixed, they're easy to deal with once you realise that the documentation is wrong. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org

Aahz

11:41 p.m.

On Tue, Feb 19, 2008, Nick Coghlan wrote:

...

Brett Cannon wrote:

...
My issue with keeping the RFEs in the tracker as they are is that it artificially inflates the open issue count. Python does not have over 1,700 open bugs.

That's a problem with our status reporting, not with the fact that there are RFE's in the issue tracker ;)

+1 -- speaking as someone who has done lots of tech support, I'm a big fan of the "one database" system. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "All problems in computer science can be solved by another level of indirection." --Butler Lampson

Georg Brandl

20 Feb 20 Feb

2:37 a.m.

Nick Coghlan schrieb:

...

Brett Cannon wrote:

...
My issue with keeping the RFEs in the tracker as they are is that it artificially inflates the open issue count. Python does not have over 1,700 open bugs.

That's a problem with our status reporting, not with the fact that there are RFE's in the issue tracker ;)

Adding a 'bug' keyword to go along with the existing 'rfe' keyword might have some merit, allowing separate stats to be reported for 'rfe', 'bug' and 'uncategorised' (neither the 'bug' nor the 'rfe' keywords have been set).

Problem is, we don't have an 'rfe' keyword anymore :) Georg

Facundo Batista

4:22 a.m.

2008/2/19, Georg Brandl :

...

Problem is, we don't have an 'rfe' keyword anymore :)

Shall we grow one again? What would happen with PEP 42? will it be deprecated? -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/

Christian Heimes

4:41 a.m.

Facundo Batista wrote:

...

What would happen with PEP 42? will it be deprecated?

It seems 42 isn't the answer at all. What a shame. *scnr* :) Christian

Guido van Rossum

5:12 a.m.

On Feb 19, 2008 12:22 PM, Facundo Batista wrote:

...

2008/2/19, Georg Brandl :

...
Problem is, we don't have an 'rfe' keyword anymore :)

Shall we grow one again?

Isn't the RFE type field enough?

...

What would happen with PEP 42? will it be deprecated?

I think it wasn't experiment that doesn't seem to have worked all that well. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

"Martin v. Löwis"

6:49 a.m.

...

...
Problem is, we don't have an 'rfe' keyword anymore :)

Shall we grow one again?

What's wrong with the rfe type? Why does it have to be a keyword? Regards, Martin

Facundo Batista

10:08 a.m.

2008/2/19, "Martin v. Löwis" :

...

...
...
Problem is, we don't have an 'rfe' keyword anymore :)

Shall we grow one again?

What's wrong with the rfe type? Why does it have to be a keyword?

For me, none. I'm just trying to converge the mail thread to a result, :) As far as I can see, the place to keep a RFE is the Issue tracker, and in the future we should decide if we deprecate the PEP 42 and move those items to the tracker. Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/

Christian Heimes

3:40 p.m.

Martin v. Löwis wrote:

...

What's wrong with the rfe type? Why does it have to be a keyword?

For one it's the name. Personally I didn't know the meaning of RFE until I googled it. Christian

Quentin Gallet-Gilles

4:25 p.m.

On Wed, Feb 20, 2008 at 8:40 AM, Christian Heimes wrote:

...

Martin v. Löwis wrote:

...
What's wrong with the rfe type? Why does it have to be a keyword?

For one it's the name. Personally I didn't know the meaning of RFE until I googled it.

I agree, the name is a bit confusing when you're not used to it. Also I find that, by definition, RFE and feature requests are not exactly the same. There's a thin line between a new feature and an enhancement that is supposed to fill a gap/improve things. Should they really be treated the same way ? Quentin

"Martin v. Löwis"

21 Feb 21 Feb

4:36 a.m.

...

I agree, the name is a bit confusing when you're not used to it.

Renaming it is easy. To the native speakers reading it: What should it be called? (please try to come up with something shorter than "request for enhancement")

...

Also I find that, by definition, RFE and feature requests are not exactly the same. There's a thin line between a new feature and an enhancement that is supposed to fill a gap/improve things. Should they really be treated the same way ?

I don't understand the difference. Can you please explain it? Are there features that are not enhancements (and if so, why would anybody request them), or are there enhancements which are not features? Are they entirely disjoint sets of things? Regards, Martin

Brett Cannon

4:39 a.m.

On Feb 20, 2008 12:36 PM, "Martin v. Löwis" wrote:

...

...
I agree, the name is a bit confusing when you're not used to it.

Renaming it is easy. To the native speakers reading it: What should it be called? (please try to come up with something shorter than "request for enhancement")

"feature request"?

...

...
Also I find that, by definition, RFE and feature requests are not exactly the same. There's a thin line between a new feature and an enhancement that is supposed to fill a gap/improve things. Should they really be treated the same way ?

I don't understand the difference. Can you please explain it? Are there features that are not enhancements (and if so, why would anybody request them), or are there enhancements which are not features? Are they entirely disjoint sets of things?

The differences are so minimal that it feels like squabbling over minute semantics. -Brett

Raghuram Devarakonda

4:41 a.m.

...

...
Renaming it is easy. To the native speakers reading it: What should it be called? (please try to come up with something shorter than "request for enhancement")

"feature request"?

How about calling it just "enhancement"?

Guido van Rossum

4:43 a.m.

On Feb 20, 2008 12:39 PM, Brett Cannon wrote:

...

On Feb 20, 2008 12:36 PM, "Martin v. Löwis" wrote:

...
...
I agree, the name is a bit confusing when you're not used to it.

Renaming it is easy. To the native speakers reading it: What should it be called? (please try to come up with something shorter than "request for enhancement")

"feature request"?

+1 -- --Guido van Rossum (home page: http://www.python.org/~guido/)

"Martin v. Löwis"

5:03 a.m.

Guido van Rossum wrote:

...

On Feb 20, 2008 12:39 PM, Brett Cannon wrote:

...
On Feb 20, 2008 12:36 PM, "Martin v. Löwis" wrote:

...
...
I agree, the name is a bit confusing when you're not used to it. Renaming it is easy. To the native speakers reading it: What should it be called? (please try to come up with something shorter than "request for enhancement") "feature request"?

I already had it at enhancement :-) In any case, by BDFL pronouncement, it's "feature request" now. http://bugs.python.org/issue_type6 (as an aside - can anybody tell me how to suppress link/unlink notifications in the history of each issue_type? I don't think we need them (unlike the reverse link's history, i.e. the history of the issue's type field)) Regards, Martin

Quentin Gallet-Gilles

6:02 a.m.

I consider a feature request something like asking a factorial method ( http://bugs.python.org/issue2138). As for the RFE, (from Wikipedia) "while not technically a bug, it is often tracked in the same manner as a bug as it represents a failure to meet expected behavior, or simply out of convenience". But on second thought, I realize I'm really splitting hairs here. It's not worth treating them separately, I'm perfectly fine with the "feature request" type :-) Quentin On Wed, Feb 20, 2008 at 9:36 PM, "Martin v. Löwis" wrote:

...

...
I agree, the name is a bit confusing when you're not used to it.

Renaming it is easy. To the native speakers reading it: What should it be called? (please try to come up with something shorter than "request for enhancement")

...
Also I find that, by definition, RFE and feature requests are not exactly the same. There's a thin line between a new feature and an enhancement that is supposed to fill a gap/improve things. Should they really be treated the same way ?

I don't understand the difference. Can you please explain it? Are there features that are not enhancements (and if so, why would anybody request them), or are there enhancements which are not features? Are they entirely disjoint sets of things?

Regards, Martin

Nick Coghlan

20 Feb 20 Feb

5:27 p.m.

Martin v. Löwis wrote:

...

...
...
Problem is, we don't have an 'rfe' keyword anymore :)

Shall we grow one again?

What's wrong with the rfe type? Why does it have to be a keyword?

It must have changed since I last looked at a feature request on the tracker - using a type rather than keyword is fine by me. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org

"Martin v. Löwis"

21 Feb 21 Feb

4:41 a.m.

...

It must have changed since I last looked at a feature request on the tracker - using a type rather than keyword is fine by me.

I'm fairly certain the rfe type was there ever since the switchover (at least that's what subversion says: the rfe type was added along with all other types in r52825, on 2006-11-23). Regards, Martin

Nick Coghlan

6:25 a.m.

Martin v. Löwis wrote:

...

...
It must have changed since I last looked at a feature request on the tracker - using a type rather than keyword is fine by me.

I'm fairly certain the rfe type was there ever since the switchover (at least that's what subversion says: the rfe type was added along with all other types in r52825, on 2006-11-23).

Perhaps we had duplication between the type and the keyword then? It's also possible I'm just misremembering and actually thinking of a completely different bug tracker that had nothing to do with Python. It's a bit of a moot point now anyway. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org

Fred Drake

20 Feb 20 Feb

1:49 p.m.

On Feb 18, 2008, at 1:21 PM, Jeroen Ruigrok van der Werven wrote:

...

A bug tracker is a much better way of registering such information. It also can be easier referenced in the future since even though when it is closed, the debate and other stuff will remain in the tracker's tickets for posterity. :)

PEP: -1 tracker: +1

I agree with Jeroen completely on this. Using a PEP for this is just plain silly. -Fred -- Fred Drake <fdrake at acm.org>

"Martin v. Löwis"

19 Feb 19 Feb

8:02 a.m.

...

This is still valid? Should we start moving RFEs to this PEP and closing their issues in the tracker?

As other have indicated - PEP 42 was a mistake (IMO).

...

Or should we try to get more discussion regarding these RFEs? Maybe, for example, a weekly digest where the latests RFEs added are sent to python-dev, so we can actually say "no way" and close them, or say "nice" and *then* moving them to the PEP (this has the risk of nobody saying anything, and to stay in the same position as before).

What do you think? Opinions?

If you think this could help, sure, but I doubt it would. I personally don't worry about these. If you don't want to see them, filter them out (roundup is very good at custom searches). Regards, Martin

5900

Age (days ago)

5905

Last active (days ago)

List overview

Download

86 comments

20 participants

participants (20)

"Martin v. Löwis"
A.M. Kuchling
Aahz
Adam Olsen
Amaury Forgeot d'Arc
Brett Cannon
Christian Heimes
Facundo Batista
Fred Drake
Georg Brandl
Gregory P. Smith
Guido van Rossum
Jeroen Ruigrok van der Werven
Nick Coghlan
Quentin Gallet-Gilles
Raghuram Devarakonda
Raymond Hettinger
Stephen J. Turnbull
Steve Holden
Virgil Dupras

Small RFEs and the Bug Tracker

Virgil Dupras

Virgil Dupras

Virgil Dupras

Virgil Dupras

Virgil Dupras

Virgil Dupras

Virgil Dupras

Virgil Dupras

Adam Olsen

Virgil Dupras

Virgil Dupras

tags

participants (20)