kicad-developers team mailing list archive
Mailing list archive
Re: no broken default fp-lib-table, removed footprint library
KiCad Developers <kicad-developers@xxxxxxxxxxxxxxxxxxx>, KiCad Librarians <kicad-lib-committers@xxxxxxxxxxxxxxxxxxx>
Carsten Schoenert <c.schoenert@xxxxxxxxxxx>
Thu, 14 May 2020 09:23:27 +0200
addr=c.schoenert@xxxxxxxxxxx; prefer-encrypt=mutual; keydata= mQINBFIDTk4BEACx6disb51q5rTdDmnkOayFDiLgOrZ4InnRmbTsgYJaigcRXjVtjFaxwL0M Qtzrt9srlLBReWD4JvoLP9/8z2C1ORaoOUatApssuKd32Qa80lBlduIQCfaZ6K5Ij0TXeqIb dWXMWSvpaOwt+ecBGSdEepgABtxO9Xel9zqDsAauFxBRHGzJs3bSG8QRtwnQA2+9J8UEtzAc dY69YAkF3Q6HIPP/0mbGiget/1WGR+8tPKlVMYcgZtGIP2J36GkDbfDvdbH5QLn2KtMuGXLv f1CTy+vvQL3mY4caKamCU7tLi8FSufNZpPChguNOHsbuO//ACrTFqGysVFvq25zEb60t9Hoq AXHIMlDJFnR7XBUCyAHV4NROMvGZlFbLuZpUA81Kukj72xifqk9ZFl9sxqKPgheqi+dT8peV LgvgCgMgQjvZgQ5X4AG2kiIezWtjlToCZAZ4ufQ26aofvwZqhBrogQF/+272B9CJuKBLIx+R CEhtW4gTKShY3moc8Aqh8AFH3pWkXILAxEGnvMu8oapAUiRNXNOb/nBlYXH1BEc+Boarm8vj LElQxdI4uNEQsLvZxsL4iYvrbZ5OLZnjkMJjvU7XVFjxAkDAHT8eYH9LWK/VeiK8fm+zsDZU qy2dN77RYlQbO9TkKlJs3CR2lpT7Dr/ObtIqEf4VFOplxTY9kwARAQABtCtDYXJzdGVuIFNj aG9lbmVydCA8Yy5zY2hvZW5lcnRAdC1vbmxpbmUuZGU+iQI3BBMBCAAhBQJSA05OAhsDBQsJ CAcDBRUKCQgLBRYCAwEAAh4BAheAAAoJEIMBYBQlHR2w8DoP/2RO8DOOA/P2Bf5atiNtEbSD nPGlN5Roml4paIPoGMw42cezBekdkJ4B/Ccr2x5MigroUTYLZwxP6U7YUNVuZhRmaEjGVD35 pIklW/os+9b5srxpdHWatHC6w/OoRL0P5EtK3sHeMOrhhMsSZe/fCiXr5VetpVgNx9fdFmSs UhkiyaBar24bLNAaY3KAAnDAUxXfQxZdYZ6kxH2Wq6sypgfq1lk4TTzGUx32nmGcR/fBZmmc +ZbZPzjd3Mor9/Dg57aMt87j/MqIndHVuucAB+/lENM4ufK04DBoqHEorD2CQJvEkn7HjydE e0YNITrFkpsqbbeltIMNV6viIxQluoYjBobY+5CRvCtYr/9m5ND0tDwHesfaBY7NWkkWhCYs M+CtlyqCtSo9Y23i/ap99GSNfguVISp8nxy3i8w/ZQ44TIRv/0zEcRoYgl/iF3wB3Gug6DVa XSZKveGMc2Q1+5u9jWfC/Jvy+J1qPM9h2m5pvTwuBrdfaMGvOzCk0iqWvHUN4cZIa8io2WXD pbbnytAhqFDFYCfgpL1Q9eczVIOO3WaITAJVHGBYnLLpsgwdsIMGXyhRO9wSpC80o2HhQK90 ifpYS1VnLJLNt2D+B31uuQr6LIuq1rtUvAzM39i3ftMLCnL1jSa+6q0uVzyTWI1xsmF7g0md ulwfQ+5zLW4KuQINBFIDTk4BEADKWf/qL0X1KWdBdTyI6qoz/1YL/hLniKAvR9J43Wtfv9EY NxRpIMGzNTOyCi/qlw0HbMo6vIxy/Tw8nTj36OjZrZQ0dFHKM66Vl4KNbA5kI0lCTj1FIjGR adMsBXWpJ44SdXF5BtAuq2/vZzYbLtjYGu5tnQrYLjGOQ0FByw3wuGnlBJVzGbbCxSB06mGa w5LXRq5HZN5zzmaiqx+z+hlOAtyo61x+gxT5BNQXGIdZkBKyzItx4OxFaiWh3JtLqSQDBkDo yzhPvEBaOFn99QUgfk4Maoj1PgFgoteKQrywY18HCtlpSMUAvX+k074kDYgrTLrh26ApECl+ bOK6P1BPWRN0uedKewnGGemJJwq2RihdpLzyHBaRlwokRH9Drs7pCsxfy9VgPCEbm7ytgzk0 EHkA7Hl/ur39TT8VLluc+zZ10xU4uuTWIBiUOeIbuJo+UVRZBFVMmsKDVQeFSi0ujz/VW/0N sW1L73406B3jYZB/bffFTGkH5acrq3cQ25Wcur92da30g5TOq3sG71+XDPVcNZgiMbDJf6tK 39rB/GjQ0Pk0O2GaiSL9tGkfjsxhZ7p5+lNCDOWWK8IAH6T7PKoIGPqRl8KmANE6qZsevgaM CWsvkJastf9a3F6ZbL15QD1qdtRebv8yhCxyikaqy8oZKWDer4pBy0oD+g9/CwARAQABiQIf BBgBCAAJBQJSA05OAhsMAAoJEIMBYBQlHR2wMKAP/iL+tk5G2vbVJCw0BKJBoMEjBedQI38l f9CeLSVtJeokIR8GkDqgTpwKJaH0/cou2Q2GUMJ5U4J/vvYFNzJk8jyT1fdC0N83HUGNKQ3H NGGcq0GQFoOHcSVeo1V77Fuf3YYhzD5mPz/ypvIvsnbuiRgxWx5meU9LfZzf8Ijzv6e67q1O G+JAKvitV4UvUo9l05ewadRg53QpWNmmRHSXflpmw0PX5C9TKsyY/Sg4DdBf2NIzktQyOxya T2yHaVuQUUQRQ0248NdA1ql7zV48ZjF1ADhagQ8bgYuGMdOW6upfUBvPqQl0poV8FwjNErex N+CUbA5inlT9oIP03LtwZoKKDuK2PojoTtGp7WZ4ryQX9i9ogUOGknAABxFg4iMBQVkyl9oF QSgHa0HlbjRj8uY1kqsO4FgrcoGiouNzEfhP5zpxvCg3BBuWngo9ApU+MXOAwuq1Gt4dzUg4 7Ir2s32nhiv5TErJzPdNrUSK/tOUZOSkOzXv1kOGbXAlhC/5a5VGfA99uFcYK899gpfB4q64 jrc3wewP0MXjVl8U004Px7sYT4BkAoCupRtmBoRWhttvbcv6T8uFMAF+j91ng0X1+n21fV+O 9wPRnD3/KJThRVMR8poUevmJbFgPfvGGmz1asVIK8tBamAZp5aCeqZ7HVkTmMbj1x07Ry7o0 iWLO
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
thanks for taking some time and writing up some sentences and opinions.
I don't wanted to blame anybody by my email, I just wanted to raise some
concerns I did have.
KiCad is not the only upstream project I package for Debian. From about
5 years experience of Debian packaging I can say that getting
information from upstream about changes is far more important than a
source tree that is building without problems. The latter is something I
I've made mixed experience with various upstream projects, there are
projects it's really a pleasure to work with and there are also projects
with it's own difficulties. Packagers don't expect they get all needed
information directly in person by upstream developers, but it shouldn't
take a long time to find all relevant stuff. Other FOSS projects have
websites that holding all the information. What does KiCad have here?
Am 13.05.20 um 15:52 schrieb Evan Shultz:
> 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
> where I specifically noted this in the commit message, but I expect the PR
> was squash merged.
Yeah, possible. Commit messages are for developers that are by nature
deeply within their project(s) and know how to read them. But well
written and organized commit messages can be an easy and excellent
source for collecting some information for a release.
For the KiCad main application this was discussed multiple times also on
the -dev list. There were some suggestions about using trigger word and
terms like FEATURE, BUGFIX so far I remember.
> 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
That's the only thing I've found so far. But also consider that such
files will mostly not get installed by the packaging tools because they
are detected as non library related. It's fully o.k. and normal to place
such an file here. But please document all these cases in a central
README file e.g. too.
This is done by FOSS projects since ever. Why not here? There is a
reason why GNU is suggesting the usage of the files COPYING, README,
> 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'
Is that somehow documented publicity? I can't find anything about this
specific but also important topic on the typical places I'd start to search.
> (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.
And here is exact the contrary point I have, packagers and also users
don't look into git history. They don't even have one as they get a
tarball as a release!
Please try to always also have a view from a user side and ask yourself
if you would expect this as user!
Talk about and announce your modifications, collect ideally some
statistics for each release. People love numbers! Make some marketing. :)
Shouldn't be that hard to enhance the existing Python tools you have to
provide some numbers about libraries and their amount of symbols.
> 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.
Fine, I'm reading this for the first time. But why wasn't this presented
to a broader audience? As written, you can't expect that every person is
stepping through the GitHub and now also also the GitLab sites to get an
> 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.
The KiCad project is one full of incredible people and developers. And
that's really great! And in my eyes KiCad is one of the best and in some
parts the only FOSS alternative to proprietary EDA tools. And as I
strongly believe on FOSS and enjoy to work with KiCad I'm happy to work
on packaging all this stuff to spread these tools.
But FOSS is nothing if we don't always also respect the users POV and
how they expected thing to behave. The gap between the software
developers and the users is filled by the packages user install and use.
But the packagers are completely depending on the information they have
and can get from the developers. And here for KiCad these people sitting
quite near to each other and we shouldn't make our free time work more
difficult and energy draining than really needed. That's mainly the core
point I wanted to show off by first email on this.
As always, it's about communication!