Reorganization proposal

[michal777]

Many libraries which creates some mess contains packages named TO or SOT. They are packages of transistors (Transistor Outline/ Small Outline Transistors) and modifications with more or less than 3 pins. They can be sorted out into:
TO_SOT_Packages_THT.pretty
TO_SOT_Packages_SMD.pretty

Following libraries could be removed:
Housings_SOT.pretty
Housings_SOT-23_SOT-143_TSOT-6.pretty
Housings_SOT-89.pretty
Housings_TO-12_TO-18_TO-42_TO-43.pretty
Housings_TO-50.pretty
Housings_TO-78.pretty
Housings_TO-92.pretty
Power_Packages_SMD.pretty
Transistors_SMD.pretty
Transistors_TO-220.pretty
Transistors_TO-247.pretty

Four footprints from Transistors_SMD goes to SMD_Packages (hard to classify them)
Six TO... from Power_Packages_ThroughHole.pretty goes to TO_SOT_Packages_SMD.pretty

KiCad/Power_Packages_ThroughHole.pretty#2
KiCad/SMD_Packages.pretty#25
KiCad/kicad-library#215
KiCad/TO_SOT_Packages_THT.pretty#1

[CarlPoirier]

I like it!

[michal777]

I think we should also decide what to do with Power_Packages_ThroughHole.pretty and Power_Packages_SMD.pretty. Should they stay or they can be removed? They may be usefull in future but now (and maybe always) they will be almost empty. Power_Packages_ThroughHole.pretty could go to Housings_SIP.pretty which contains only one package.

[CarlPoirier]

Michal, it would be great if we could merge this before the stable branch is created. I'm looking at it now. Are you done?

[CarlPoirier]

I'm fine with the changes. So all the footprints in the libraries to be deleted listed above have been copied over to the new libraries, right?

As for the Power_Packages_*, I'd leave them intact.

One last thing, if we use _THT in the library name, then we better use it for all of them. Either that or we put _ThroughHole. I'm fine with renaming the other ones but it may make some folks angry again.

[michal777]

Only variants (CBE/GDS) of TO-220 are deleted.
There are still things to improve but if all the changes will be merged it will be better starting point to work on it - not so much libraries to care about.
I like THT more (shorter) but now it can be ThroughHole and in future some bigger renaming can be discussed.
About Power_Packages... I'm afraid if they will irritate users if they will be almost empty - there is very long list of very small libraries. If they will be left it should be defined what will they contain. Class of Power_Packages is overlapping with TO, SOT, IR-DirectFETs, some of QFN etc.

[michal777]

I added another pull request to SIP that will allow to remove Power_Packages_ThroughHole.pretty.
I think it's necessary because the name is confusing and the library 'overlaps' with others.

[odurc]

@michal777 can we go with this merge?

[michal777]

For me it's ready to merge. I don't know Carl's opinion about the SIP packages, I don't know when/if he will go back.
I think it's not really important where the "power packages" will go, more important thing that needs to be discussed with leader is what to do with some old libraries left on github. The new footprint wizard allows fetching everything from this github page (option "select all" that people probably will use) so users get very messy libraries. This must be solved somehow.

[odurc]

For me too, it's OK to merge.

I don't know Carl's opinion about the SIP packages, I don't know when/if he will go back.

Yes, there is a long time Carl doesn't appears.

I think it's not really important where the "power packages" will go, more important thing that needs to be discussed with leader is what to do with some old libraries left on github. The new footprint wizard allows fetching everything from this github page (option "select all" that people probably will use) so users get very messy libraries. This must be solved somehow.

You mean that ones you said "could be removed"? If so, I agree, the only way to avoid this messy is removing them, having duplicated footprints would be a pain.

[odurc]

@michal777 After see your proposal and comments, I've been thinking about to extend this reorganization to all footprints repositories, but I guess users would hate it and them would stay very unhappy/angry/furious with us. Take a look and please comment what do you think: KiCad/kicad-library#257
(Surely we should wait Carl to move this ahead)

[michal777]

I think that what really makes useres unhappy is poor quality of the libraries and it's necesasry to make more changes.
The changes in footprints library probably won't be as painfull as some time ago. The new library wizard: 1. suggests to use local libraries, 2. suggests downloading libraries from github and saving on hard disk, 3. if somebody really wants he can use libraries online (probably not many users will do it - online libraries is bad idea and people know about it), so online libraries are no longer default and whats more the wizard builds fp-lib-table (users don't have to use our fp-lib-table).

[CarlPoirier]

Hi guys,

Sorry for my absence. I am in the process of moving and have no access to an online computer with KiCad. I cannot have a look at any contribution. I'm almost done and I should gain access back this week however.

I say we go ahead with this merge since it has been discussed on the mailing list a good while ago and people have been warned. @ricardocrudo, your suggestions in the new issue are great in general. I'd have only some minor adjustments. The thing is we need manpower for applying such changes. I cannot help right now. I will have to try the new features in the footprint wizard as well.

[CarlPoirier]

I will be merging this now. We will keep the libraries to be removed a little while but mark them as deprecated. This is for the folks who are not updating their kicad-library often.

[CarlPoirier]

Thanks Michal for your contribution.

[michal777]

Maybe we should ask developers for popup redirecting to library wizard if library table is empty and if it will be done remove library table from github forever?
I think this will solve the problem unless users will force the wizard to add libraries as online.
I think that keeping old libraries is bad because there is no easy way to download only the up to date set of libraries.

[CarlPoirier]

What if the wizard downloaded the libraries according to the fp-lib-table
from github? It could ignore those marked as deprecated.

On Tue, Aug 4, 2015 at 3:22 PM, michal777 notifications@github.com wrote:

Maybe we should ask developers for popup redirecting to library wizard if
library table is empty and if it will be done remove library table from
github forever?
I think this will solve the problem unless users will force the wizard to
add libraries as online.
I think that keeping old libraries is bad because there is no easy way to
download only the up to date set of libraries.

—
Reply to this email directly or view it on GitHub
#1 (comment)
.

[michal777]

If old libraries must be kept in master branch this would help to ignore them (if somebody will implement...) so it would be better than now. Maybe if wizard would use branches the problem could be solved in a better way. I think that the best solution would be to remove any fp-lib-table from kicad-library and keep libraries clean.
The problem with fp-lib-table, wizard and old libraries should be solved before stable release. Otherwise users will get ugly set of libraries with plenty of duplicates and think that the libraries are even worse than they really are.

[CarlPoirier]

We'll make sure to remove them before the stable release.

On Thu, Aug 6, 2015 at 11:48 AM, michal777 notifications@github.com wrote:

If old libraries must be kept in master branch this would help to ignore
them (if somebody will implement...) so it would be better than now. Maybe
if wizard would use branches the problem could be solved in a better way. I
think that the best solution would be to remove any fp-lib-table from
kicad-library and keep libraries clean.
The problem with fp-lib-table, wizard and old libraries should be solved
before stable release. Otherwise users will get ugly set of libraries with
plenty of duplicates and think that the libraries are even worse than they
really are.

—
Reply to this email directly or view it on GitHub
#1 (comment)
.