69262 - Share versions and milestones across products

Status: NEW

(Bugzilla :: Bugzilla-General, enhancement, P3)

Description

[Matthew Tuck [:CodeMachine]]

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.

Comment 1

[Matthew Tuck [:CodeMachine]]

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.

Comment 2

[Matthew Tuck [:CodeMachine]]

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'

Comment 3

[Jacob Steenhagen]

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).

Comment 4

[Dave Miller [:justdave]]

Moving to real milestones...

Comment 5

[Hixie (not reading bugmail)]

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.)

Comment 6

[Matthew Tuck [:CodeMachine]]

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

Comment 7

[Eric Hanson]

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?

Comment 8

[Matthew Tuck [:CodeMachine]]

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.

Comment 9

[Eric Hanson]

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

Comment 10

[Matthew Tuck [:CodeMachine]]

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?

Comment 11

[Eric Hanson]

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).

Comment 12

[Hixie (not reading bugmail)]

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?

Comment 13

[Eric Hanson]

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.

Comment 14

[Hixie (not reading bugmail)]

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

Comment 15

[Dave Miller [:justdave]]

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.

Comment 16

[Hixie (not reading bugmail)]

Bailing on Bugzilla 3.0 due to too many other commitments.

Comment 17

[Max Kanat-Alexander]

This Bugzilla3 bug is not actually going to be in the real Bugzilla 3.0.

I think we have dups of this bug, somewhere.

Comment 18

[Frédéric Buclin]

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

Comment 19

[Frédéric Buclin]

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

Comment 20

[Onno Garms]

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.