kicad-developers team mailing list archive

[Eeli Kaikkonen <eeli.kaikkonen@xxxxxxxxx>]

On Fri, Mar 20, 2020 at 1:20 AM Seth Hillbrand <seth@xxxxxxxxxxxxx> wrote:

> Hi Eeli-
>
> It looks like the example you noted was a mistake.  If it is marked a
> duplicate, you can click the "Closed (duplicate)" blue button at the top
> to follow to the base issue.
>
>
Yes, I can follow to the base issue by a couple of means (also by following
the status change messages amongst the comments), and I knew it already.

You can search for duplicate issues by selecting the "All" or "Closed"
> when you search.  I'd really like to avoid recreating the GitLab
> functionality with labels.


No, I can't search for duplicate issues. I can see the closed issues, but I
can't search for duplicate issues or see that an issue is duplicated unless
I open that specific issue first. That's what I said. On the other hand
labels can be searched for or explicitly left off from the results, and are
directly visible in the issue list without opening each issue.


> There are more features in GitLab that link
> to the "duplicate" mark that are useful.  Specifically, in the base
> issue, we get a list of the duplicates that a developer can look over
> when creating their work package.  The features involved in the work
> package are reviewed by the rest of the development team, which helps to
> ensure we catch the parts of the issue that are important to address.


That answers my one question. It's OK if this is part of the normal
workflow. I just haven't seen any discussion or mention about this until
now, and it can't be seen in the issues (which are what the reporters and
other end users read). Now when you have said this and if the other
developers agree and do that, I can know what happens to duplicates.

This is still valid:

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

You reacted to the example by changing the report to a duplicate. OK, but
it doesn't help a user who reads the issue chain and wonders why a
seemingly or possibly unrelated issue was marked as duplicate. It would
help if a short explanation would be given. Jon gave an explanation
<https://forum.kicad.info/t/does-kicad-have-the-features-i-use-in-altium/21467/59?u=eelik>
in the forum thread which I linked to:

It is not explicitly mentioned, but once KiCad can keep track of pad stacks
> for every hole, it is possible to modify pad stacks for individual holes
> easily. Pad stacks include all layers that are relevant to holes, including
> masks.
>

In this case a shorter explanation would suffice: "mask layer should be
included in padstack". Then a careful reader can know that the duplicate
status isn't a mistake and that the developers consider the issue as part
of the larger issue or feature.

This is, of course, only one example. I have seen others, and that's why I
wrote my mail.

In the forum I once gave a link to
https://gitlab.com/kicad/code/kicad/-/issues/2295. In the forum a user
sceptically commented
<https://forum.kicad.info/t/configuring-the-grid-sizes/19709/24?u=eelik>:

The bug report was deleted after it was marked as a duplicate of another
> vaguely related issue…
>

In this case "vaguely related" is an accurate description indeed. How these
reports are related and how this report is a duplicate of another could
have been epxlained in a comment. I.e. how implementing the other feature
would either implement this feature, too, or would make it needless or
superfluous. It's easy to see those two bugs "related", much more difficult
to see them as duplicates.

Also in this case the point is NOT this one report, but the general problem
of not seeing the exact relationship of two reports of which one is closed
as being a duplicate. It would help if the reason for duplicate status
would be explained. It may be obvious to a developer who changes the
status, but not to those who later read the reports.

Eeli Kaikkonen