ncoghlan at gmail.com
Sun Sep 26 13:43:55 CEST 2010
On Sat, Sep 25, 2010 at 1:12 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> > But how should a performance improvement be filed? Bug? Feature request?
>> > Or should "feature request" be renamed "improvement"?
>> It's a feature request (since we won't backport it unless there is a
>> genuine performance problem being addressed as a bug fix). Whether
>> that warrants changing the name, I don't know.
> I think most people won't intuitively file performance issues as
> "feature requests", since it doesn't sound like a feature.
>> A third option for
>> "other improvement" may also work (since that would also cover things
>> like clarifying doc wording, fixing comments, adjusting code to be
>> more readable/obviously correct, etc).
> But then why not keep a clear categorization of these "other
Because it's asking people to make a decision too early in the
process. The clear categorisation as to what *kind* of
bug/feature/improvement it is can be supplied later on by selecting
the appropriate components and keywords.
> By the way, doc wording fixes and cosmetic code changes often get
> backported. :)
Yep, hence why I think the basic "bug, feature, other" split may be a
good way to go. It's a quick and easy decision most of the time
(including a clear choice for "I don't know if this is a bug or not"),
and makes a meaningful procedural distinction (bugs are usually
backported, new features are not, and other changes may be backported
depending on the details).
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-Dev