Re: Duplicate bugs: shall we follow strict chronological order?
On Thu, Feb 11, 2021 at 09:46:03AM +0100, Marcus wrote: > Am 11.02.21 um 09:03 schrieb Arrigo Marchiori: > > I want to mark some duplicate bugs and I have a question. > > for your example, see comments inline. > > > Suppose the bugs are numbered 2, 4, and 6. I have been working on > > number 4, because I did not know about number 2. For this reason, > > number 4 has more comments on BugZilla and my GitHub PR refers to it. > > > > I will declare that no. 6 is a duplicate, because it was reported > > afterwards. > > yes > > > Can I indicate that no. 2 is a duplicate of no. 4 even if it was > > reported before, although according to a strict time-based logic it > > should be the opposite (i.e. that no. 4 is a duplicate of no. 2)? > > Yes > > > The reason I believe it would be better to flag no. 2 as duplicated of > > no. 4 is because report no. 4 contains much more data about the > > problem and IMHO it should ``stand out'' with respect to the others. > > +1 > > In general: > > Following the chronological order is the right thing. This means the oldest > issue will remain when all others are decribing the same problem. > > Exceptions (of course ;-)): > > The respective issue should survive when: > - it has the most helpful comments > - it already has a doc to reproduce the problem > - it has already a reference to SVN / Git / GitHub ... > - it has the most votes, or links to "see also" issues > - it has in general most helpful data. > > That means chronological yes, but maybe it makes sense to use another issue > when it is more helpful and then close all others as duplicate. > > > Thank you in advance for your guidance, > > I hope this is helpful for you. > That's the way I'm doing it. Very helpful! Thank you. Best regards, -- Arrigo http://rigo.altervista.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Duplicate bugs: shall we follow strict chronological order?
Hi Arrigo, Marcus, @Arrigo Thanks for bringing this up. @Marcus Thank you for this extensive explanation. It will surely help me a lot in my bug hunting tusks - ykwim. ;‑) "Exception that proves the rule". Regards, Czesław чт, 11 февр. 2021 г. в 09:46, Marcus : > Am 11.02.21 um 09:03 schrieb Arrigo Marchiori: > > I want to mark some duplicate bugs and I have a question. > > for your example, see comments inline. > > > Suppose the bugs are numbered 2, 4, and 6. I have been working on > > number 4, because I did not know about number 2. For this reason, > > number 4 has more comments on BugZilla and my GitHub PR refers to it. > > > > I will declare that no. 6 is a duplicate, because it was reported > > afterwards. > > yes > > > Can I indicate that no. 2 is a duplicate of no. 4 even if it was > > reported before, although according to a strict time-based logic it > > should be the opposite (i.e. that no. 4 is a duplicate of no. 2)? > > Yes > > > The reason I believe it would be better to flag no. 2 as duplicated of > > no. 4 is because report no. 4 contains much more data about the > > problem and IMHO it should ``stand out'' with respect to the others. > > +1 > > In general: > > Following the chronological order is the right thing. This means the > oldest issue will remain when all others are decribing the same problem. > > Exceptions (of course ;-)): > > The respective issue should survive when: > - it has the most helpful comments > - it already has a doc to reproduce the problem > - it has already a reference to SVN / Git / GitHub ... > - it has the most votes, or links to "see also" issues > - it has in general most helpful data. > > That means chronological yes, but maybe it makes sense to use another > issue when it is more helpful and then close all others as duplicate. > > > Thank you in advance for your guidance, > > I hope this is helpful for you. > That's the way I'm doing it. > > Marcus > > > - > To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org > For additional commands, e-mail: qa-h...@openoffice.apache.org > >
Re: Duplicate bugs: shall we follow strict chronological order?
Am 11.02.21 um 09:03 schrieb Arrigo Marchiori: I want to mark some duplicate bugs and I have a question. for your example, see comments inline. Suppose the bugs are numbered 2, 4, and 6. I have been working on number 4, because I did not know about number 2. For this reason, number 4 has more comments on BugZilla and my GitHub PR refers to it. I will declare that no. 6 is a duplicate, because it was reported afterwards. yes Can I indicate that no. 2 is a duplicate of no. 4 even if it was reported before, although according to a strict time-based logic it should be the opposite (i.e. that no. 4 is a duplicate of no. 2)? Yes The reason I believe it would be better to flag no. 2 as duplicated of no. 4 is because report no. 4 contains much more data about the problem and IMHO it should ``stand out'' with respect to the others. +1 In general: Following the chronological order is the right thing. This means the oldest issue will remain when all others are decribing the same problem. Exceptions (of course ;-)): The respective issue should survive when: - it has the most helpful comments - it already has a doc to reproduce the problem - it has already a reference to SVN / Git / GitHub ... - it has the most votes, or links to "see also" issues - it has in general most helpful data. That means chronological yes, but maybe it makes sense to use another issue when it is more helpful and then close all others as duplicate. Thank you in advance for your guidance, I hope this is helpful for you. That's the way I'm doing it. Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Duplicate bugs: shall we follow strict chronological order?
Dear All, I want to mark some duplicate bugs and I have a question. Suppose the bugs are numbered 2, 4, and 6. I have been working on number 4, because I did not know about number 2. For this reason, number 4 has more comments on BugZilla and my GitHub PR refers to it. I will declare that no. 6 is a duplicate, because it was reported afterwards. Can I indicate that no. 2 is a duplicate of no. 4 even if it was reported before, although according to a strict time-based logic it should be the opposite (i.e. that no. 4 is a duplicate of no. 2)? The reason I believe it would be better to flag no. 2 as duplicated of no. 4 is because report no. 4 contains much more data about the problem and IMHO it should ``stand out'' with respect to the others. Thank you in advance for your guidance, -- Arrigo http://rigo.altervista.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
