kicad-developers team mailing list archive

[Carsten Schoenert <c.schoenert@xxxxxxxxxxx>]

Hi Rene,

Am 15.01.2018 um 18:14 schrieb Rene Pöschl:
> Faster releases motivate contributors.
> Remember: Most contributors add new stuff. Bugfixes are mainly
> done by the library team.

Fully Agree here. If you can manage it to make monthly releases I see no
real reason to not do it then. And a lot of of the technical work can be
automated.

...
>> Adding new libraries isn't that problematic as they are just 'new'.
>> Removing a library is a thing that doesn't have to happen, never ever!
> 
> That is why it might be a good idea to uncouple the software and library
> version cycle. If the lib has a separate cycle we can inform users over
> changes more easily.

I also agree on that. That's why I asked for the release circle and the
planned versions for this.
For the packaging side it has become unhandy to always wait until the
next point release of KiCad got offered while most people 'just' need
the new libraries. OTOH the complain from Wayne about the targeted KiCad
version of the libraries is also valid. But this is only a question of
the string for the tag in the git tree.

...
>> Some more information about the current plans and doings in the library
>> team would be a good thing! And please not only through the KiCad user
>> forum. Please use also the KiCad website and/or the new GitHub site for
>> the libraries you have created.
> 
> Not sure what you mean here. The new libs are not yet official. Once they
> are we will make a blog post about them.

Well, it was (and is) difficult to follow what is happen on the side of
the libraries, at least this is my impression. Communication is motsly
done by the GitHub issue tracker (which I find horrible to use) and I
guess within the KiCad forum. That's o.k. so far. I just want to mention
it's not easy for new people and also for me as someone who is packaging
all that various stuff to get easy actual information about the work and
plans of the library people.

About 1.5 to 2 years ago there I started to work with KiCad most of the
time I have tried to research around the usage and modification on the
libraries. It's now much better but cut be even better. And that 'even
better' is just a small step in my eyes. Hopefully now it's a bit mor
clear what I've tried to say.

...
> Believe me. No matter how long you think about the names you will never
> find everything that you want to change at a later date. We discussed the
> current new names for over half a year.

I think I know what you say and I don't want to blame anyone here. I
just want to bring the problems on top probably not only I've found.

What me often helps in such situations is to really try to look at
myself and my work like other would do. So, how does this all looks for
someone from outside? What would he expect to see or to find. Is the
work or the goal I try to get really useful for other people?

I know that is difficult but if it would be easy others would already
have done the work.

To get others peoples view they need to know that some feedback is
appropriated. And this brings the circle again to the communication.

...
> The libs for version 4 still live in their old repos ;).
> 
> As far as i know, no further version 4 release is planned.
> 
> We have already archived most of the old repos.

What ever that means in times of git. :-)
But I got that you mean. And I suspect the core library team won't do
any maintenance of the old stuff proactive. But wanted to raise the
question as I know that some users of Debian can't follow the two years
release circle and need to stay on older versions and than ask mostly by
the bugtracker (in Debian) about new updates for their old versions. But
I can't answer such questions without to know what upstream is thinking
about. Maybe the library team want's write a small statement about the
situation of the libraries/symbols for the older version?

> Another thing to consider:
> 
> It is hard to find what symbol/footprint is correct. Even if the contributor
> states it worked for their project, a different pcb manufacturer might still
> have problems with it. A symbol (or footprint) can be in the library for
> 
> years and nobody finds out that it is incorrect. (We found a few footprints
> 
> while reworking the libs, that where incorrect for the last 3 years.)
> 
> The library can not be compared to software in this regard.

I disagree on that as from the source view there is no difference
between both. But yes, one (or even more) person(s) can't do here any
serious quality testing work due the current and increasing amount of
symbols. This can only be done by automatic testing and as the libraries
internally have always the same structure this will make it mostly
easier to write some autotests.

But let us stop here, further discussing here brings no gain right now.

-- 
Regards
Carsten Schoenert