An update has been posted. The next release is now very near. (Wayne wants to have it done by tomorrow)
https://lists.launchpad.net/kicad-developers/msg37914.html
Nor do you want to with finite developer power available. Beter to address issues/functionality which can not be solved with external tools.
As I said, I a posting here with my packagers hat on. I am completely fine with using git, but I do not expect everyone else to be.
There are two possibilities here - either require the datasets or let the user handle it. If the datasets are not available, the relevant function (PCBnew, EEschema, 3d Viewer) will not work as expected (no componen/part to place, no component shown). As there is no error/warning message shown, a possible first time user will get frustrated ā¦
For the symbols and footprints (which are separate packages for us) we have chosen to require them, but for the 3d packages weighting between size and need resulted in keeping it optional.
Of course using git is an option from a āis it working perspectiveā - but not as a default choice. If library management were so easy, you would not have to devote any FAQ entries to it. It is not only about using git, but also the awareness it is available.
I do no ask for a git replacement, but for a well integrated way to use it. Even a message in the library dialog would help significantly. If you push away first time users, it gets hard to gain new developer resources.
Not all developer resources are equal. This could be a task for someone who is relatively new to KiCad development. For sure it is not something critical, but what is wrong with acknowledging it is a weak spot?
I have contributed to the KiCad documentation build system in the recent past, but getting these kind of answers let me reconsider any further involvement.
This is all already there with the standard packages. I merely suggested an alternative as you wanted a way to download only needed information. Git is simply king in this regard. Everybody who wants an easy solution just has to deal with the fact that it will be more expensive on the download volume side. (Everything in technology is simply a tradeoff. In this case ease of use vs. download volume)
If you push away first time users, it gets hard to gain new developer resources
People often say that sort of thing, but Iāve never seen any evidence for it. I donāt think the two things are in any way linked.
I have contributed to the KiCad documentation build system in the recent past, but getting these kind of answers let me reconsider any further involvement.
The āif you donāt play my game I will take my toys awayā approach never gets any traction.
Even if we all agree that seamless git integration was a vital and necessary feature, you canāt just wave a magic wand and make it happen.
The Linux packaging is quite a mess, which Windows users donāt suffer, but all platforms suffer from a lack of integration with libraries. It should be a lot easier to install/update/remove libraries.
Personally I would like to see a tools API that allows any VCS to be added via a plugin, but itās far from a show stopper.
The Linux packaging is quite a mess, which Windows users donāt suffer, but all platforms suffer from a lack of integration with libraries.
Why do you think packaging KiCad or the libraries is being a mess on Linux? Contrary to Windows every Linux distribution has a package management system and packaging the stuff is a almost automated thing. I donāt see any mess here. Understanding the package management is one thing, the most important thing is the human resource on this part.
It might be a bit confusing as there is not one standard of how the packages are named and split. Some distros use one large package for everything while others have the libs split away into separate packages. (These later distros sometimes supply a meta package for adding all library packages with one command. This results in another inconsistency.)
Being slightly off topic, Iāve found that a lot of times on this forum (as this is the only forum I regularly participate where members are from all around the world) that two persons can express them self completely differently due to different language, cultural background and professional experience all the while meaning the same thing.
Back on topic, I agree with you that even a little bit of VCS (git or in general) integration support would go a long way especially for handling the libraries, but I havenāt got a clue where to begin with. And even if I had an idea what to implement, that would still not be enough as C++ is not really my forte. Thus I dable a little bit with python and try to expand the KiCad ecosystem with action plugins.
As for the documentation, I also agree with you, but Iāve found out that before publishing anything, it has to be tested, as it can do more harm than good (a big thanks goes @bobc). Thus I am testing the documentation how to integrate git with KiCad library management in my local KiCad usergroup in my mother lanugage, and when it will be refined, Iāll try to include it in official documentation
Being slightly off topic, Iāve found that a lot of times on this forum (as this is the only forum I regularly participate where members are from all around the world) that two persons can express them self completely differently due to different language, cultural background and professional experience all the while meaning the same thing.
In the same way, two users may appear to be speaking of the same thing, or may appear to be in agreement on some point, when in fact they are not. Posting screen shots or the applicationās native files often helps to resolve both types of error. The discrepancy may not originate with language or culture - it may be due to differences between hardware engineers and software engineers; developers versus āordinaryā users; coming to the discipline of PCB layout from mechanical versus electrical training; previous experience with some other EDA tool; or even chronological age.
When a multi-national, multi-cultural forum (such as this one) is successful, the users have learned to allow a wide ātolerance bandā for language usage, and to consider the possible alternative meanings for a post. I am asking the Forum members to forgive me for the times, both in the past and in the future, when my vocabulary, English language structure, or logic are simply too complex, or ambiguous, or misleading. It is not intentional.
I am testing the documentation . . . in my local KiCad usergroup in my mother lanugage, and when it will be refined, Iāll try to include it in official documentation
That is an excellent start. Especially if your local KiCad usergroup has not had any involvement with developing either the KiCAD program, or the documentation. The next step, of course, is to test any translation on a similarly uninvolved group.
Dale
P.S. - I looked on your user profile for a clue to what your first language might be. You have not put any information in the āAbout Meā section.
Itās possible that you will never see 5.0.1. Instead 5.0.2 will be released within a week. For the reason see https://lists.launchpad.net/kicad-developers/msg37932.html and forward.
1 KiCad week is about 8 human weeks. Therefore the prediction above was correct. See https://lists.launchpad.net/kicad-developers/msg38454.html.
God, if I only have 1 month to live let it be in NBA final two minute time? Apology to those that donāt get the sports reference.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.