RFE versus Bug group Feature Request

[terryjreedy]

BPO	964703
Nosy	@gvanrossum, @tim-one, @loewis, @freddrake, @terryjreedy
Files	sumcvs.py

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/tim-one'
closed_at = <Date 2004-06-05.17:12:58.000>
created_at = <Date 2004-06-02.02:14:19.000>
labels = []
title = 'RFE versus Bug group Feature Request'
updated_at = <Date 2004-06-05.17:12:58.000>
user = 'https://github.com/terryjreedy'

bugs.python.org fields:

activity = <Date 2004-06-05.17:12:58.000>
actor = 'tim.peters'
assignee = 'tim.peters'
closed = True
closed_date = None
closer = None
components = ['None']
creation = <Date 2004-06-02.02:14:19.000>
creator = 'terry.reedy'
dependencies = []
files = ['1291']
hgrepos = []
issue_num = 964703
keywords = []
message_count = 11.0
messages = ['20960', '20961', '20962', '20963', '20964', '20965', '20966', '20967', '20968', '20969', '20970']
nosy_count = 5.0
nosy_names = ['gvanrossum', 'tim.peters', 'loewis', 'fdrake', 'terry.reedy']
pr_nums = []
priority = 'normal'
resolution = 'wont fix'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue964703'
versions = []

[terryjreedy]

The Category is 'Source Forge Item Tracker'. The
possible bug is the redundancy of having both an RFE
(Request For Enhancement) list separate from the Bugs
list and a Feature Request Group within Bugs. Is this
intentional or an historical artifact that should be
removed in order to direct feature requests one place or
another.

[tim-one]

Logged In: YES
user_id=31435

Sorry, we can't do anything about this. Group names cannot
be deleted in SourceForge's system, and can't even be
renamed. So we'll have a "Feature Request" Group in the
Bugs tracker forever -- or unless SF changes their system.

When we first moved to SF, RFE trackers didn't exist. That's
why Bugs grew a Feature Request group to begin with.

Closing as 3rdParty, WontFix.

[terryjreedy]

Logged In: YES
user_id=593130

In the meanwhile...
is it appropriate to recommend that requests go in RFE (as I
somewhat ignorantly and indirectly did today, see bpo-960325)
or is this a "don't care" issue for the developers (that I should
ignore)?

[tim-one]

Logged In: YES
user_id=31435

Oh yes! Overall, we'd rather reduce the mushrooming backlog
of patch and bug reports than slam in new features, so we
want to keep feature requests out of the bug tracker. That's
why the RFE tracker was added.

[terryjreedy]

Logged In: YES
user_id=593130

Thanks for the clear directive.

A thought for feature requesters: Conflicts between promise
(the References) and performance (the CPython
implementation) are clearly bugs. So to are sufficiently
muddled docs. While a 'missing' feature might look like a bug
to one who wants it, it might not to a developer looking to
prune a bloated bug list (>700 today, about double what it
was not too long ago.) On the other hand, a feature request
in the smaller RFE list is only competing with other feature
requests instead of sometimes serious bugs.

[freddrake]

Logged In: YES
user_id=3066

I will note that not everyone agrees on this. Having to
look in multiple trackers is quite painful as well.

The separation of the RFE tracker would be less of a problem
if there were no "patches" tracker; a patch should be
attached to a bug report or to a feature request, not separate.

Grr.

[gvanrossum]

Logged In: YES
user_id=6380

We should switch to RoundUp on python.org. A single unified
tracker that we can modify. Grr.

[loewis]

Logged In: YES
user_id=21627

fdrake: I deal with the RFE tracker by never (or very
infrequently) looking at it. If Python has 700 bugs, and 250
unreviewed patches, I'm not going to implement features that
people have requested just because they requested them. So I
would be happy if the RFE tracker grew to 700 items, if the
bugs tracker shrank to 150 entries simultaneously. Only at
that point I will wonder what to do next, and look at RFEs.

[terryjreedy]

Logged In: YES
user_id=593130

loewis: I currently interprete your advice to me as "Yes,
encourage movement of RFEs to the RFE list so I can focus
on real bugs" rather than "No, leave them so I can reward
queue jumpers with attention I would not otherwise give". ;-)

There are people who *have* read and responded to RFEs
(about half have been closed). Even those rejected usually
get more explanation than simply "Not a bug"

all: I agree that a tracker that we can modify with experience
to make review and response easier would be great. I agree
with fdrake about patch confusion. I think there should
either be no separate patch list (but a way to pull out items
with an open patch), or all patches should be on a separate
patch list, but linked to a discussion-only item. I'd like a way
to select boilerplate responses and check off the presence of
required patch features.

[loewis]

Logged In: YES
user_id=21627

Yes, the RFE tracker is a way for me to move things at the
end of the queue (or the bottom of the stack).

I agree that all patches should be in the patches tracker,
i.e. patches should not be attached to bug reports. Instead,
the bug should have a comment "I have created a patch for
this bug at python.org/sf/something", and the patch should
start with "this fixes python.org/sf/somethingelse". I then
process the entire thing by opening two tabs in Mozilla, and
a shell window:

• I download the patch from the patch tab
• I test it in the shell, and commit it
• I run my "sumcvs.py" (attached) to extract the essential
  bits from the CVS commit message (files and version numbers)
• I possibly repeat the procedure for release23-maint
• I put a comment in the bug saying that it is fixed with
  mentioned patch, and close the bug
• I put the commit info into the patch comment, and close
  the patch as accepted

This is a routine procedure, which takes a total of five
minutes administrative action (plus time to actually read
the patch, compile it, etc.)

[tim-one]

Logged In: YES
user_id=31435

Note that since SF doesn't let anyone other than the OP or a
tracker admin attach a file to a report, someone who wants
to contribute a patch generally must create a new tracker
report to do so. That's the reality we live with here. It's less
confusing to put those in the patch tracker than to grow an
additional "bug report".