kicad-developers team mailing list archive

[Eeli Kaikkonen <eeli.kaikkonen@xxxxxxxxx>]

I have some questions and suggestions regarding duplicate issues in the
gitlab issue database.

First, gitlab can mark issues as "duplicate". It will become " Closed
(duplicated)". However, 1) there's no way to search for that status AFAIK,
and 2) it can't be seen in the issues list (it's just Closed) and I have to
open the issue to see if it was a duplicate or not.

Could it be possible to add a new label, "duplicate". It should then be
added  manually to the issues which are marked as duplicates. That way both
1) and 2) would be fixed.

Second, some larger questions.

What are the requirements for an issue to be marked as duplicate? Let's
take a chain of issues as an example. (See
https://forum.kicad.info/t/does-kicad-have-the-features-i-use-in-altium/21467/59?u=eelik
where Jon's comment etc. was written after I drafted this mailing list
message.)

In issue https://gitlab.com/kicad/code/kicad/-/issues/2163 Jeff says "
Closing in favour of #2014 (closed)." However, this issue 2163 isn't marked
as a duplicate. The main thrust of this report is a wish to add tenting
(mask) option for each via.

In https://gitlab.com/kicad/code/kicad/-/issues/2014 we have "full stack
for each via". This, in turn, was marked by Seth as a duplicate of
https://gitlab.com/kicad/code/kicad/-/issues/2402. This 2402 is milestoned
for v6 but is in the "future" roadmap and doesn't have an assignee.

I see some problems with this kind of issue chain.

1) It's difficult for the users (and the developers) to follow this chain
and find related issues. An end user may want to find "via tenting" but
it's closed (without actually being marked as a duplicate). Via tenting
isn't mentioned at all in the final issue and not even in the middle
issue.The intent of the original report has been lost in the issue chain.

2) If issues are closed and/or marked duplicates like this and they are
difficult to track down, how can reporters know that their issues are
actually being considered and remembered?

3) Can we be sure that when the final issue is fixed and closed that the
original (closed as duplicate) issue has been solved? When the final issue
is finally assigned to someone, can we know that this someone browses
carefully through the issue chain and all related issues of all related
issues to see if all the issues are really fixed, and the remaining issues
are possibly re-opened? Can we be sure that in this example case Jeff, Seth
and whoever will implement it in the future have understood it in the same
way? There's no explicit information about the intentions of those who have
made changes to the statuses of the reports.

(People's names are mentioned strictly only because they are real world
examples, no further implications should be made about assumptions about
anyone's intentions or working habits or anything else. Everyone has been
doing good job.)

Does anyone else see these as problems?

I would suggest that if an issue is marked as a duplicate but it's not an
exact duplicate or isn't self-evident - like exactly the same clearly
defined bug reported by several users - the one who marks it as a duplicate
would give an explanation. Then the developer who fixes an issue or closes
it would be responsible for going back through all issue chains and
carefully read all reports to see if they are actually fixed.

It would also help if gitlab had a way to mark relationships of issues in a
more fine-grained way than just "related to". For example "supersedes" and
"is superseded by". That could of course be done with a label and
explanation comment. If an issue isn't actually a duplicate of another, but
implementing another feature would include fixing this one or would make
this one unnecessary, the bug could be marked as "superseded". IMO
"duplicate" isn't a good label for an issue which is related but isn't
actually a duplicate - duplicate would mean "this issue covers everything
but nothing more than that other one", or at least so much that it's
self-evident to whoever reads them.

The main point is that even the ordinary end users should be able to feel
confident about the status of each issue when they read it.

Eeli Kaikkonen