[development] Bug fixing stalled?

Greg Knaddison greg.knaddison at gmail.com
Mon Jan 9 14:18:34 UTC 2006

On 1/9/06, Bèr Kessels <ber at webschuur.com> wrote:
> I mailed the development list about another important setting: "post 4.7". A
> lot of bugs are *real* bugs, but have been around for a long while, or are
> not critical for a release for 4.7 [1]. But *really are* bugs.
> Being able to "postpone them for after 4.7" might be a good idea. Using the
> postponed status is not an option, since we then use the "patch" etc status,
> as well as that there is no indication untill when its postponed.

Yes, that makes sense, kind of.

I believe that the "version" field is for the version where the
problem/feature request was found.  There should ideally be another
field for "version targetted to fix the problem"

I was thinking more about my comment that we need a "not repeatable"
entry added to the "status" but I think that we really need a
"resolution" field separate from status (though comments suffice for
now) to track what happened rather than the "status".  The "status"
may be "active" but that doesn't tell us whether it is waiting to be
verified, verified as a bug and needs to be fixed, or "not

So, the total of Bèr and my recommendations:

1. New "Targeted Milestone" field which contains the release where the
bug is hoped to be fixed (also helps with changelogs/release
announcements) which would include post 4.7
2. Severity field separate from priority
3. Resolution field separate from status with corresponding new values.

Ironically, this seems like "post 4.7" work ;)


More information about the development mailing list