On 1/9/06, Bèr Kessels <ber@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 repeatable". 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 ;) Greg