Liviu Andronic wrote: > While I understand when people want to remove milestones since "if no > one is working on them they're meaningless", I also agree with > Guillaume's arguments here: a milestone usually contains some > information about the bug, its intended scope and its importance. The > mere fact that it has a milestone means it's that bit higher in the > priority list, even if no one is actively working on it right now.
Yes, we do currently use milestones like this (and we should transfer this information to some other setting), but I don't think that this is how most people expect milestones to work. > My solution would be as follows: > All bugs with 2.2.0 or 2.1.4 milestones, which no one is currently > working on, should be retargeted to 2.2.x or 2.1.x milestones. This > way we do not lose milestone information, and the 2.x.x milestones are > not blocking releases nor confusing people as to whether someone is > actively working on them. Yet, they conserve the triaging information, > which is indeed a collective effort in itself. The 2.x.x are thus > simply placeholder milestones (what they always were), not getting > into anyone's way but allowing someone to pick up on important stuff, > whether they're new on the block or simply a regular devel with more > spare time. We did retargeting to .x milestones for many years already, and it did not work (see e.g. #4118). Having a milestone (whether it is a specific one like 2.2.0 or a more fuzzy one like 2.2.x) implies that it is planned to fix this bug for that milestone. However, this assumption is wrong for many (if not most) of our bugs. IMO it is better (both for developers and users) to be honest about the bugs that can be expected to be fixd for a particular release. Your proposal is still better than the current situation (where milestones are basically useless if one wants to know when a particular bug will be fixed), because this uncertainty would be limited to the .x milestones, but I would still prefer a solution where even the .x targets are more meaningful. I think that Guillaumes proposal to use the priority is more consistent whith user expectations: A bug with high priority is important. We would probably need to adjust our bug searching habits a bit (and I'd also like preconfigured views in trac that show high priority bugs), but then it could work. Georg
