On 20. Jun, 2013, at 6:32, Olemis Lang wrote: > On 6/19/13, Gary Martin <[email protected]> wrote: >> > [...] >> >> 1. do we care that a ticket with a duplicate relationship might get >> moved to a new product? > > IMO we first have to define what is «moving a ticket to another > product» . Now it's meaning is fuzzy and there are open questions > (e.g. product-specific ticket seq number is the first thing I recall) >
Agreed, we should resolve the ticket numbering first. >> >> 2. with the constraint that users can only set newer tickets as >> duplicates of older tickets, will that just be confusing when the user >> attempts it? >> >> I'm asking the second question partly because if I happened to have done >> work against a newer ticket before spotting a duplicate, I would >> probably want to close the older ticket as duplicating instead. >> > > In my opinion this constraint is not worthy . A notable > counter-example is the very same ticket opened by andej in trac issue > tracker for IResourceChangeListener . It was the last one and , > considering the fact that the approach was considerable different to > all previous attempts all other (previous) tickets were closed as > duplicate and phased out in favor of the new solution proposed / > discussed in there . True. Furthermore, since we will allow multiple duplicate relations for a single ticket, this constraint IMO makes even less sense. > > -- > Regards, > > Olemis.
