We probably won't use the following fields : -- target milestone (we already have the version for that) ? But : Mandriva has added it recently to their bugzilla, you can see cooker bugs with target 2011.0. But will we have bugs in cauldron we *don't* plan to fix for the coming release ? -- estimated hours -- deadline We should remove them, and maybe add them back later if we see a use for them.
ok for deadline this is fixed on my local copy ( fixed it on the server too but puppet will erase my change soon ) What about the milestone field, i don't see it.
i removed the fields .
Status: NEW => RESOLVEDResolution: (none) => FIXED
Priority: --- => Normal
What about feature requests ? We might not want to introduce some changes for some release and postpone them for the next releaseâ¦
CC: (none) => shikamaru
(In reply to comment #3) > What about feature requests ? We might not want to introduce some changes for > some release and postpone them for the next release⦠I don't get what you mean here :/
CC: (none) => ahmadsamir3891
(In reply to comment #4) > (In reply to comment #3) > > What about feature requests ? We might not want to introduce some changes for > > some release and postpone them for the next release⦠> > I don't get what you mean here :/ I got it : he means that for feature requests, the "milestone" field could be useful. Indeed, bugs should be fixed for the next version, but features can be postponed. Better use the milestone field than the "LATER" status.
The Milestone field was never used/useful in the two years I was a member of the triage team in mdv... not sure it's going to make a difference for our use (it makes sense in an upstream bugzilla, e.g. mozilla bugzilla, e.g. "this feature will be in firefox-4.0b12".... etc, but not much sense in a downstream bugzilla). Just my 2 cents; if many people think it's useful, it can of course be added back...
I would have kept the milestone, at least to experiment with it, but for some specific features or bugs for a given release (as a target, indeed). So that features (big or small) may be planned in advance for a given release.
CC: (none) => rdalverny