kicad-developers team mailing list archive

[Evan Shultz <evan.shultz@xxxxxxxxx>]

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.schoenert@xxxxxxxxxxx>
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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>