|
The enhancement request database has now
been organized. Some of you who
have submitted RCRs in the past probably saw a flurry
of bugzilla activity over the last few weeks. This should calm down now. It is interesting to see the stats. Since January 1999, 37 people have
submitted 476 feature requests, not counting duplicates. 227 (48%) of those resulted in a
software enhancement being implemented.
We currently have 66 requests assigned to our development staff. Here is the full breakdown by submitter:
total FIXED LATER DUP INVAL WONTF NEW/U NEW/A cathis 11 5 3 1 2 cathyc 7 1 1 3 2 dmitry 3 3 don
7 3 2 1
1 donaldb 1
1 frankk 1 1 glanca 2
1 1 gregf 57 20 10 6 2 14 1 4 ian
14 4 2
4
4 ingrid 1
1 janeb 6 2 2 2 jasonw 2 2 jeffh 13 2 3 4 1 2 1 jeffhintz 65 40 8 5 2 6
4 juanr 6 3
1 1
1 jwdean 5 3
2 ken
44 20 8 3 2 5
6 kerry 1 1 klong 2
1
1 kponti 2
2 ldix 7 6
1 lesley 6
3 2 1
marke 7 3 1 1 1 1 mike 13 5 2 3 1 2 nel 76 38 10 4 2 7 3 12 ravina 3 1
2 robertc 9 4 2 1 1 1
rodney 11 2 2 3 3 1 sophia 15 3 3
2 3
4 steveh 2 1
1 stevek 53 17 10 14 4 1 7 tarir 66 28 12 10 5 5
6 tiredale 9 5 1
3 tracyt 3 2
1 virest 2 1
1 whitman 4 4 total 544 227 86 68 37 56 4 66 -----Original Message----- At the close of business today we
will be shutting down the RCR majordomo mailing list. The motivation is pretty much the same
as with the old bugtrack mailing list that was shut
down in June. Of late the RCR
list has become a bit of a dumping ground, with no one really knowing the
status of their requests. We hope
that by putting all requests into the bugzilla database we can apply some rigor
to the process. We want to give
people an honest picture of what requests to expect in upcoming releases, and
just as important, which requests not to. When submitting new feature
requests, set the Severity of the “bug”
as Enhancement. This will keep the feature requests separated
from bugs in existing releases. You
can leave the Version field as unspecified.
Obviously the version of the feature doesn’t exist yet, so there
is nothing to fill in there. All of
the old
rules for submitting RCRs still apply.
If a RCR turns out to be better characterized as a bug (or visa-versa),
we can always change the severity after the fact. There are new hyperlinks on the main
bugzilla page for My RCRs and My RCRs in Purgatory. You can use these to see the status of
your feature requests. All of the
previous RCRs from the majordomo list have been imported into bugzilla. It will take some time to work through
these, but we hope to have them sorted over the next couple of weeks. In the mean time, don’t take the
current status of your requests as gospel. The basic modes are: NEW, unassigned: The feature request has not yet been
reviewed or assigned to anyone. LATER: The feature may be implemented some day,
but is not on our 3-6 month development horizon, and will not likely make it
into the next upcoming major release. NEW/REOPENED, assigned: The feature has been assigned to a
project lead, and will be implemented in an upcoming release. WONTFIX: In all likelihood, this request will
never be implemented. INVALID: There were not enough details given to
implement the request. The request
is functionally in the same state as WONTFIX until more information is provided. Please don’t take the WONTFIX
state personally. We would love
nothing more than to implement everyone’s requests, but tough technical
and business realities often make that impossible. If you feel that your request has been
unjustly rejected, bring it up with the executive committee and see if you can
get it resurrected. Just because
something is on the WONTFIX pile does not mean that it must stay there
forever. If the right technical or
business circumstances present themselves, the request could become a
reality. The reason for this state
is simply to try to be honest with people about their request, rather than
putting it on the LATER pile where LATER won’t in reality come before
hell freezes. The LATER pile is basically an
un-prioritized list. We may one day
make use of the priority field of bugzilla, but for now our priority (pardon
the pun) is to let people know if their request will: (1) make it into a foreseeable release,
(2) make it into some release way out in the future, or (3) never make it into
any release. We might one day start
fine-tuning the far out horizon; for now though, knowing which of those three
slots a request fits into will be a big improvement on what we have now. Ken |