The most-used packages in the pool will be generic ones, i.e. packages with standardised names used by multiple manufacturers. The pool’s folder structure mirrors their importance by placing them right into packages, using the manufacturer sub-folder for other, more special packages.
As it came up during the discussions linked above, this distinction currently isn’t very well-defined in the convention. Problems can arise when different vendors have different ideas about some otherwise generic packages. This can include varying physical dimensions (and thus a different package layer and courtyard) or different pad dimensions for the land patterns.
When creating a package for the pool, you wouldn’t notice there are differences between vendors just from looking at your particular part’s data sheet, so what should the process be for new generic footprints? We want to arrive at a situation where the generic package is the most useful and covers most manufacturers. True universality cannot be guaranteed as checking every existing part with the package name in question won’t be feasible, so we’ll have to find a best-effort solution.
I see three main ways of approaching this:
Require a contributor to check drawings from multiple manufacturers before adding a generic package. Reviewers for a PR containing a generic package would naturally have to check a number of drawings from different vendors, too.
Don’t restrict generic footprints, but require later contributors to move packages which are, in retrospect, not generic to manufacturer folders, e.g. if the new part’s land patterns don’t agree with the existing package’s. Naturally, you’d have to check with at least a third manufacturer whether the existing package or your new one should be the generic one.
Always create new packages as manufacturer-specific. When creating new parts, check existing packages from other manufacturers and promote a package to generic if the drawings agree.
Neither solution is perfect, but I’m tempted to prefer the second one because you’d have to validate the footprint for every new part anyway. With the first option, the bar for a generic footprint would be raised significantly and we might end up with lots of identical copies in different manufacturer folders. The last option provides a way around this, but appears to be the most complicated and brittle to me.
Discussion from #12 and #15 continues here.
The most-used packages in the pool will be generic ones, i.e. packages with standardised names used by multiple manufacturers. The pool’s folder structure mirrors their importance by placing them right into
packages, using themanufacturersub-folder for other, more special packages.As it came up during the discussions linked above, this distinction currently isn’t very well-defined in the convention. Problems can arise when different vendors have different ideas about some otherwise generic packages. This can include varying physical dimensions (and thus a different package layer and courtyard) or different pad dimensions for the land patterns.
When creating a package for the pool, you wouldn’t notice there are differences between vendors just from looking at your particular part’s data sheet, so what should the process be for new generic footprints? We want to arrive at a situation where the generic package is the most useful and covers most manufacturers. True universality cannot be guaranteed as checking every existing part with the package name in question won’t be feasible, so we’ll have to find a best-effort solution.
I see three main ways of approaching this:
Neither solution is perfect, but I’m tempted to prefer the second one because you’d have to validate the footprint for every new part anyway. With the first option, the bar for a generic footprint would be raised significantly and we might end up with lots of identical copies in different manufacturer folders. The last option provides a way around this, but appears to be the most complicated and brittle to me.