What to do about incorrect symbols in default libraries?

Sometime ago, when I was drawing some of my first schematics in KiCAD, I needed the symbol for the MC6840 programmable timer.

When I called up the library for the schematic, I was instead given what turned out to be the symbol for the MC6821 (I ended up making my own symbol for the 6840).

How does one go about making suggestions for corrections?

MC6840 appeared in https://github.com/KiCad/kicad-library/pull/1719 which was a 2nd attempt by a different author of https://github.com/KiCad/kicad-library/pull/895. It seems the first PR had the correct symbol, but for some reason the real MC6840 graphics got replaced with a copy of 6821.

I think the other MC68xx symbols are ok, just MC6840 symbol got messed up.

Thanks for the link. I’ll check it out, especially since I found another hiccup…

The 74HC04 should be an alias of the 74LS04, but instead is an alias of another CMOS inverter chip.

You either go through the 50+ steps on the GitLab site, including codes, IDs, authorization, checkout etc., or you make your own library.

Like to guess what I did?

1 Like

In 5.1.9 it is an alias of 74LS04

I am not a software person and I did not have much difficulty to use KiCad. But I gave up on trying to figure out Gitlab.

Sadly, hackers and spammers get everywhere, so authentication of some sort is needed. I don’t recall gitlab being specially difficult, but then I use these sort of tools in my day job.

If anyone needs to raise an issue, they could just ask here. I don’t mind raising issues on other people’s behalf, if I think it is valid.

2 Likes

I just hate to see people discourage others.

I do not know their motives, thoughts or anything, but the other options (encourage or even neutrality=not saying anything) seems to me like a better move.

@Meterman2026 for the symbol repo, issues are here: https://gitlab.com/kicad/libraries/kicad-symbols/-/issues

After having a GL account, i am not sure if it is more than 3 clicks away to open an issue… I believe this is not a difficult task.

GL is a little confusing but this requires to spend some time navigating around and figure things out. GL also has a strong documentation in order to help you.

2 Likes

Ah, okay. For a variety of reasons I wound up rolling back to 5.1.6.

If you are willing to raise the issue on my behalf, I can drop the MC6840 symbol I made into a fresh library and attach it to this thread.
(If further encouraged, I can throw in some other ICs for which I made my own symbols: 2-part versions of the 74LS368 and 74LS375 ICs; MC6810; MC6850; and 2716 / 2732 EPROMs)

Ah, the offer only extends to creating issues for incorrect symbols; submitting merge requests for new or changed parts is another level of effort which I would not have time for.

That’s one point of looking at it. I call it the “Why can’t we all just be friends?” approach. And it’s deadly.

Having worked most of my life in engineering combined with sales and marketing, I’ve learned that complaints are extremely valuable and should be taken seriously.

A customer (and I’m a customer in this case) that calls in with a complaint does it, because he wants the issue to be solved, and would like to continue working with you. This is positive feedback.

A customer that keeps silent or doesn’t complain, is lost to you forever.

I understood your point of view.

In this particular case though, the way i see it, OP is asking for a more appropriate place to raise an issue.

Nobody benefits from hearing the same complains over and over. But it is your right to express yourself and that is acceptable from me.

I do not want to accept over-reactions though. Raising an issue is not a big deal, and it is not 50+ steps away. Neither checkouts required, neither git and terminal. I think you can agree here.

I do feel the need to point you that as an open source “customer”, it goes against your own benefit to discourage anyone from contributing.

This is another point of view…

4 Likes

All that is required is providing gitlab with a valid email address (or a account on any single sign on service like google, github, …). In other words no more work required than getting an account on this forum.

Two factor authorization is optional (can however be set as a requirement for a repository or organization). Source: I am the reason (or one of them) why the KiCad organization does not require two factor authorization (or more precisely my lack of a smartphone capable of running the app required for two factor authorization).

I am not even sure if two factor would be required for pull requests or issues even if the organization requires it for their members. This assumption comes from the lack of write access needed for either of these actions (issues do not change anything on the target repo and pull requests require you to have a personal fork whose access rights are under your control)

Right.
I’ll try GitLab again some day when I have nothing else to do.
To be fair, my nightmarish experiences were with GitHub, and after seeing that GitLab looks exactly the same, I pulled the emergency brake immediately. I’m not a masochist.

Let’s see.

Cheers.

1 Like

Time is definitely not with our side :smiley: But KiCad’s great community is. I hope you get the time to enjoy also this contributing part sometime…

Both are based on Git, so have the same basic functionality (forking, merging, pull request, etc.) but they have slightly different auxiliary features. I don’t know what they are, but apparently the KiCad dev team liked the auxiliary features of GitLab over GitHub when they went shopping for where to transition away from Launchpad.