kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 09/30/2013 09:25 AM, Carl Poirier wrote:
> Hi guys,
> 
> My replies to some of your comments are below.
>  
> 
>     That table currently gets set only on entering the dialog.  I will look at this and see if
>     I can trigger another env-var fill after editing any lib path (uri).
> 
>      
> 
>     The env-var table should be read only.  I am working on that today and will change it to
>     such.  This env-var table is just a reminder, not a tuning agent.
> 
>      
> 
>     It will show any environment variable referenced in a LIBPATH, if that env-var is in the
>     libpath at time of invoking the dialog (for now).  Only those environment variables
>     referenced in a libpath are shown. 
> 
> 
> Actually it was me not knowing the difference between shell and environment variables. I
> got it to work now, although the changes in the env are only reflected once I restart
> pcbnew, and not when I close and open again the library dialog.

I assume you mean the value column, not the variable name column.  Variable name column
comes from the libpaths, whereas the value column comes from the environment, which can
only be changed before the program loads (or from within the program) to my knowledge.


> 
>     The last step is to push to GITHUB.  I don't see a reason to wait, since the
>     footprints can live in several places at once.  The real question is when do we shut
>     down the BZR library repo, not when do we push to github. For now, you could make each
>     *.pretty directory its own github repo, local to your work environment. Each should be
>     a separate repo I think so that they end up being separate repos on github. [...] Once
>     you do that, you can then push each repo to a place on github, hopefully under
>     a common github user, and publish that base user location on this list.
> 
> 
>     No problems getting GITHUB_PLUGIN to build. I've not connected it to a github
>     repository as I run out of time last night to generate a library. I'll have a look at
>     it tonight and see how things go.
> 
>  
> I can work on pushing the libs to github today. However, can you please explain to me what
> you intend by a "common github user"?

This is intended to mean either:

1) a *common* github account (common to all fp libs) that is for your use preliminarily,

or

2) if you are committed to being a maintainer, then you could register a pretty/kicad
specific project and plan on offering commit rights to additional footprint maintainers as
well.  This could lighten the burden, but reduce the quality.

Either of the above creates a base directory on https://github.com.  Within that base
directory, the individual repos would exist, all at the same level, but each in their own
repo.

Then when establishing the fp table for such a collection of github resident pretty
footprint libraries, a person *could* then use an environment variable:


   ${GITHUB_PRETTY}/pin_array
   ${GITHUB_PRETTY}/smd_resistors


outside kicad:

export GITHUB_PRETTY=https://github.com/carl  or whatever.


Any common base name is what I meant by a common user:

	https://github.com/liftoff-sr/pretty_footprints
	https://github.com/liftoff-sr/.....
	:


no environment variable usage is required, but if it is, any can be used and defined.





> 
>     We will soon need an official github librarian for the official kicad footprints.  This
>     will require somebody to volunteer for that responsibility.
> 
> 
> Actually I might be interested in that, but I'd like to know more about the involved
> tasks. Since KiCad is the first project I contribute, you will guess that I've never been
> an official maintainer.


(If you want to be maintainer, then please join the kicad-lib_committers launchpad mailing
list.

	https://launchpad.net/~kicad-lib-committers

If they talk, I guess that is where.  Cleaving off the footprints from launchpad could
argue for a separate mailing list.  I don't care, I'd just like someone to take charge,
and do the footprints on github in pretty format so we can all use the github plugin.
That is my main goal.)


> 
> Finally, I have included the script to generate the pretty libs as well as the column swap
> in the attached patch. As for the library table that gets saved automatically in ~, what
> do we want to do with that? I have also attached it.


I guess the maintainers will need to host their pretty footprints locally, so they can
edit and push them to github as they change.  I'd ask this question on the library
comitters list.

Again, I only care about the footprint repos on github short term.  Short term is
desirable as it lets start testing the github plugin, and walk before we run.

Thanks for your successful contribution!

Dick




> 
> Carl