rusefi.com

As of June 2019 https://github.com/rusefi/rusefi repo still has KiCad version 4 files. Technically there are two issues here - first issue is that we have a huge repository with both firmware and hardware, second issue is that we have legacy KiCad version 4 files.

We also already have https://github.com/rusefi/kicad-libraries which is a bit confusing since at least I have no idea which files are K4 which files are K5 and etc.

We also have https://github.com/rusefi/hw_modular which as of June 2019 has both KiCad version 4 and KiCad version 5 files... What a mess.

It is my honor to present https://github.com/rusefi/hw_legacy where totally not needed any more stuff would go. I will have to spend more time going over https://github.com/rusefi/rusefi/tree/master/hardware and moving more stuff to https://github.com/rusefi/hw_legacy

I am sure that at least some stuff like Frankenso at least we would need to eventually convert to KiCad version 5. Open question is what should be the roadmap to the conversion and if we even understand what exactly is needed to do the conversion right.

I guess first step should be to convert the relatively young https://github.com/rusefi/hw_modular and learn there. Maybe first step would be to find something useful KiCad version 4 from https://github.com/rusefi/rusefi/tree/master/hardware and convert it into version 5 while moving it to https://github.com/rusefi/hw_modular

Should we ask more hypothetical questions like the below? Once we know these, then we can figure out how we can get it there.
-- With current and future revisions of KC, should we consider repo names which include what version of KC is compatible? I know that with code this is considered sacrilege, but this is hardware and hardware in a git repo is already it's own odd duck. With this being hardware, should we consider having the matching KC version in the repo names? I believe Linux kernels are done this way, with repos being specific to the higher level OS name.
-- KC has an archive button, should we be using the KC tool for this kind of thing? How does KC expect users to work in repositories?
-- Should we have a rusEFI lib or should the libs be included with each project?
-- Should a board with it's own symbols and footprints, have those footprints and such it's own repo, or in a higher level repo?
-- Should each board have it's own repo, or should we have one repo with many sub modules.
-- Should we make our properties match a library like the digikey lib. Following similar field names, and such.

My thought is that we should have a repo structure like this.
Hardware_KC4
|-->Board1
|-->Board2
|-->BoardHistory
|-->KC4_Libs

Hardware_KC5
|-->Board3
|-->Board4
|-->BoardHistory
|-->KC5_Libs

I have mixed emotions on the global library vs the project specific libraries. I like updating one lib and it some times updates multiple boards. I do not like that we often have libs which were only ever used on one project. So I tend to be 50/50 on if we should have a global lib or project specific libs. I also don't like having to search several project looking at project specific libs, to find a footprint. As well the one time use files are going to be worse over time. They never go away. So I guess while I don't like the clutter of the single files getting in the way, I have a slight preference to the more global libs like we have now.

Then official releases should be a PDF, or a zip file, etc. Keep in mind the repo is only for developers, while users should be getting the files from a different download link.