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 -- Mailing list: https://launchpad.net/~kicad-lib-committers Post to : kicad-lib-committers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-lib-committers More help : https://help.launchpad.net/ListHelp
