[Tracker-discuss] Feature/Change request handling procedure

["Martin v. Löwis"]

Erik Forsberg schrieb:
> I fully agree that you should be able to turn a feature request into a
> bug very easily, and that is exactly why I think the main class should
> not be named "bug". I don't want another class for feature requests, I
> want the main class to cover as many types of issues (see, there it is
> again, the perfect word for it! :) as possible. 

I may have missed some discussion; IMO, to the end user, the name
of the main class should be invisible. It can be called "bug", "issue",
"contribution", or "jabberwocky". As an end user, I don't want to have
to type the name of the main class into the computer, ever. In
particular, I hope that I can refer to some issue as
bugs.python.org/<issue>.

> At work, where we use bugzilla, we use milestones a lot. Typically,
> during a week, a bunch of new bugs are found. They are entered into
> bugzilla and the milestone is then set to '--' which is bugzillaish
> for "not yet decided". During our weekly development meeting, we then
> iterate through the bugs with milestone "--" and set the milestone to
> something more appropriate such as "release X.Y". 

In Python, we never do that. By default, all contributions are targeted
for the next release, with two exceptions: when the next release is
close, we tell (in natural language) the submitter that there is no
chance it can go into this release. The other exception is that some
patches are submitted towards Python 3 now.

SF has a field indicating a version number - we use that to record
in what version a bug was found, so it always talks about past versions,
not future versions.

We currently use priorities to show
- that a submission should be integrated into the next release if
  at all possible
- that a submission blocks a release, i.e. we can't release without
  that issue being resolved
That distinction is mostly made just before a release; a single
"target version" field would not help as it would not distinguish
between blockers and non-blockers.

> The above provided as an example of why I think being able to set
> milestones from the bug display is important. The python-dev people
> might use a completely different procedure (some kind of Silly Walk,
> perhaps? :)  )

See above. In open source, it is really unrealistic to assume that
a bug can be fixed with a given deadline. It may well take years
to fix a certain bug even if the bug is critical in some contexts.
Even for patches, we now have patches that have been completely
unreviewed for more than three years. So setting target versions
is just day-dreaming.

Regards,
Martin