[Tracker-discuss] Feature/Change request handling procedure

[Stefan Seefeld]

Martin v. Löwis wrote:
> Stefan Seefeld schrieb:
>> Erik Forsberg wrote:
>>
>>> Personally, my opinion is that it should not be "bug", because one
>>> might also want to enter feature requests (which are not bugs) and
>>> other kinds of "issues", which takes us back to "issue" which is a
>>> nice and general name. OTOH, I guess the Python project handles its
>>> feature requests mostly by PEPs, so perhaps everything entered into
>>> this database will actually be bugs?
>> Well, I thought we would eventually handle PEPs, too !
> 
> 
> I'm not quite sure what you mean by that. No, the Python project does
> *not* handle feature requests mostly by PEPs; many new features are
> added without any discussion at all (like adding a new optional
> parameter to an existing function, or supporting a new release of
> an operating system where the old release was supported).
> 
> PEPs are there primarily for controversial new features; if there is
> no controversy, there is no point in writing a PEP. Also, PEPs are only
> for "major" new features, where the effort of writing a PEP is justified
> because it is still smaller than the effort of implementing and
> defending it.
> 
> PEPs aren't handled through the tracker, and shouldn't be. PEPs are
> discussed on many forums, and the PEP authors have the task of merging
> all comments into the PEP text.

I see. FWIW, what I had in mind was similar: have a 'feature request'
enumerator that can be set in the 'type' property of bugs, suitable for
the 'minor' features you talk about.

And, have a completely different issue type 'pep' that has its own life
cycle, which could help to manage PEPs. Actually, I think it was amk who
mentioned the possibility to handle PEPs in the tracker.
I have no opinion whether PEPs should be handled with the tracker or not,
but it certainly *can* be done, even with all the required infrastructure
such as handling the evolution of PEP documents, managing discussions
across suitable mailing lists or other media, etc.
I can see the tracker making the life for PEP authors easier.

>> But, may be this is really up to the people who will actually deal
>> with these issues to decide whether they want it that way or the other.
> 
> I can repeat was voiced earlier: the SF view of having separate lists
> (for bugs and patches) is confusing. Things that start out as a bug
> report often get a patch added, at which point they should become
> "patches". OTOH, some "patches" primarily report a bug, and the patch
> provided is not useful. So it seems the users want a single list.

Yes, I agree.

> I also can report that some users (including yours truly) would
> prefer to rank reports based on whether patches are included, giving
> higher priority to issues that include a proposed solution.

How would you tag patches (attachments, generally) to decide / indicate
whether it actually contains a patch and not some other content, and whether
it really fixes the bug ? Doesn't this involve at least some developer
interaction anyway, at which point we could simply set a 'contains fix'
flag that would be part of the bug type, or absorb into the status
enumeration as 'fix_provided_but_needs_testing', as suggested earlier ?

>> That's an interesting point. Milestones are mostly associated with
>> particular branches, while bugs (at least in my suggested schema)
>> could be associated with multiple versions / branches. Isn't that
>> an argument in favor of putting the link between bug and milestone
>> into the milestone, not the bug ? :-)
> 
> It should be easy to close a bug at once for both the trunk and the
> "active" maintenance branch. Backports should occur immediately and
> along with actual fix (IMO); people following this policy should have
> an easy way of closing the bug "twice".
> 
> OTOH, we have lived well so far without including a "closed in
> this branch only" field. Submitters occasionally complain that
> they though it was closed only to find that the next bugfix
> release did not include the patch (because the fix was on the trunk
> only); these days, presence of multiple svn revision numbers
> can be taken as an indication that it got fixed on multiple
> branches.

OK.

Thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...