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
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
