kicad-developers team mailing list archive

[Carsten Schoenert <c.schoenert@xxxxxxxxxxx>]

Hello Evan,

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
simply expect.

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:
> 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.

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
> https://github.com/KiCad/kicad-footprints/tree/master/Connector_Multicomp.pretty

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,
INSTALL, LICENSE.

> 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.

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.

https://kicad.github.io/
https://kicad-pcb.org/libraries/contribute/
https://kicad-pcb.org/libraries/klc/#_footprint_guidelines

> (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
full overview.

> 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!

-- 
Regards
Carsten Schoenert