Carsten, It was was my PR that was merged ( https://github.com/KiCad/kicad-footprints/pull/1586) which removed these footprints. In the initial PR comment I noted removing the Multicomp footprints and it was also discussed in later comments. Those footprints were deleted with commit https://github.com/KiCad/kicad-footprints/pull/1586/commits/acce9a43b8e105b28db62589c71c37036af8446e, where I specifically noted this in the commit message, but I expect the PR was squash merged.
When something similar happened in the past, I created https://bugs.launchpad.net/kicad/+bug/1820305 (now at https://gitlab.com/kicad/code/kicad/-/issues/2360). And I was careful to check that this PR didn't cause similar problems. I can understand requesting some readme file, and in this case I did leave a readme file in Connector_Multicomp library but I edited the file to specifically tell the user where to find the compatible footprints. See https://github.com/KiCad/kicad-footprints/tree/master/Connector_Multicomp.pretty . In a general sense, we (I am also a librarian) have learned from issues in the past. We know that removing footprints (not symbols!) won't cause issues for existing designs so we allowed this change during a 'minor' release. (Note that we try to only merge changes that would affect existing designs if there is a bug being fixed that outweighs any user trouble.) There are many changes happening with each release and we have let GitHub capture the discussion and resolution (as it was done here). There may be some notable changes to the library worth announcing during minor releases, but usually keeping some running readme file for the library as a whole would only duplicate work for no benefit I can see. Also note that Rene was careful to review symbol cjanges and he did provide a summary of things that could impact users at https://github.com/KiCad/kicad-symbols/issues/2656#issuecomment-626880880 before tagging the library as 5.1.6. All this is to say we will try not to repeat past issues but we are human and can't prevent making new ones. While it's great you're taking such an active interest in things and advocating for KiCad users, I expect you have a lot to do and would prefer that KiCad and other programs will take care of themselves. I believe we have done that here and will continue trying to do so in the future. Evan On Tue, May 12, 2020 at 10:43 PM Carsten Schoenert <c.schoen...@t-online.de> wrote: > Hello Rene, > > Am 12.05.20 um 22:58 schrieb Rene Pöschl: > > What is broken here? The old library folder is still there to ensure > > users do not get an error message. Footprints are embedded in the design > > files so no negative impact on old designs. The new footprints are > > vastly superior to the old ones so the tradeoff is simply worth it! > > I'm glad that you can refute my concerns as this means in the end that > users don't get interruptions. And that's what I want and need to take > care on. > > ... > >> Keeping that entry makes no sense to me if the folder is now empty. > > Yes we could remove the entry but our CI script would complain -> so we > > decided to just have the empty lib it does not hurt anyone. > > So more a problem to get this reason publicity visible then? > > ... > > Well now you know why we keep the empty folder. (At least v5 does no > > longer crash with a missing lib.) > > No, I don't know this, otherwise I wouldn't ask, the experience of > releases from past was it was a problem. As written previously, I do not > and can't follow all the various developments in all places, to many > various places with different platforms for development. > > ... > > The two bug reports you list again clearly show why we now keep the > > libraries as empty instead of removing them. > > O.k. to summarize, the movement of footprints within libraries isn't a > problem (any more) as long the old now empty directory is still shipped? > Sounds like a issue to me. > > I will try to do a bit of testing but this isn't possible to do this > manually for every release as the cases you want or need to test will > immediately growing. I haven't the time to do such things. > > It would have been really helpful for me if things like above would get > communicated in a better way. The simplest thing is a text file within > the repository, mostly called README. :) > I haven't found any information in the git tree, in the mailing list, on > the KiCad website or on GitHub. > > -- > Regards > Carsten Schoenert > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp