It would be nice if we could support simultaneously released products, for example Mozilla MailNews & Mozilla Browser, or GNOME 1.4. These products want separate votes, etc., but still want to share milestones. The only thing they have is that they have the same milestones/versions. If there was a facility to join them: - we could edit their milestones & current milestone in one place - you can bulk change milestones across these products.

Note that just having the same milestone text should _not_ be interpreted as being the same milestones. M1 or 1.0 on one product might be a totally different date than on another. What matters is that you've explicitly said they use the same milestones.

It is possible that you might have subgroups in a hierachy that add extra milestones. I'm not sure how useful it would be. At the very least, all products should share '---' & 'Future'

This would be useful for me as I use time-based milestones (2001-02, 2001-03, etc.) and have to set it up on each product (and then can't mass update when Feb. becomes March).

Moving to real milestones...

Taking all Bugzilla 3.0 bugs -- congratulations to MattyT for the triage, it really was spot on. Note: I may end up pushing some of these bugs back to 3.2, we'll see. However, I believe all these bugs should just fall out of the redesign. Let's hope I'm right! (Note: I'm also resetting the priority field to "---" so that I can retriage any that I consider important or likely to be dropped.)

*** Bug 61992 has been marked as a duplicate of this bug. ***

My bug was just marked as a dup of this one and I wanted to clarify the proposed functionality of this bug. I agree that the duplicate target milestones across products is good, but will you still be able to have milestones in a product that aren't duplicated to other products? Even if it is "sharing" milestones with another product?

Sorry, not sure I understand. Are you saying you want to share versions but not milestones? We certainly won't force any products to use the same milestones as any other products.

Sorry, I was unlcear :) What I meant is that you would have product A and B. Product A would share the same milestones/versions that B does, but B would also be able to have other non-shared milestones/versions. I think this sounds reasonable, but I just wanted to make sure that it was part of the spec so that if it wasn't I could reopen by dupe bug. Thanks

Well, I mentioned a hierachy earlier, but I was not sure that anyone had a use for it. Could you please explain what you would use it for?

I guess I don't understand what you mean by a "subgroups in a hierachy". Could you give an example? I just want to know which functionality you propose: 1) You would be able to add non-shared milestones/versions to a product in addition to having shared ms/vs. 2) You could have non-shared ms/vs or you could have shared ms/vs. In other words if a product is using another product's versions/milestones, you cannot assign it additional ones (ones not shared).

Say you have field M (maybe milestones) and field P (possibly products). Field M has values M1, M2, and M3. Field P has values P1 and P2. In the new design, it would be possible to say: Field M has controlling field P. Value M1 is available if field P has value P1. Value M1 is available if field P has value P2. Value M2 is available if field P has value P1. Value M3 is available if field P has value P2. ...which would mean P1 and P2 would "share" M1, and in addition P1 would have M2 and P2 would have M3. Is that clear?

Now I am really confused. Why does P2 imply M1 and M3? It seems arbitrary that if field P contains P2, that it would share M1 and M3. Unless these rules are set by the user? It seems you are trying to do something very complex and slightly different from Bug 61992 that you marked as duplicate. I will reopen 61992 with greater explanation so that it is clear that these two bugs are different. Thanks for your time, sorry for being so dense.

Eric: This would be completely set by the user, yes. (Where the 'user' is the Bugzilla administrator.)

The Bugzilla 3 component is going away. We're going to depend on the Milestones for this. At the time this component was created, we didn't have milestones for Bugzilla.

Bailing on Bugzilla 3.0 due to too many other commitments.

This Bugzilla3 bug is not actually going to be in the real Bugzilla 3.0. I think we have dups of this bug, somewhere.

*** Bug 352099 has been marked as a duplicate of this bug. ***

*** Bug 202297 has been marked as a duplicate of this bug. ***

Open for more than a decade :-( As long as this is not implemented: 32 bit sortkeys would help a lot: We work around this problem by having a rule to convert the milestones deadline date into a sortkey. (We don't want to use the deadline field, because it's the raw date isn't that handy and because the date should be stored per milestone rather than per in each bug.) With 16 Bit signed, conversion is rather tricky: %y%V%u where y is two-digit year V is weak of year (01..52 or 53) u is day of week With a 32 Bit signed, we could encode much more human readable.