kicad-developers team mailing list archive

[Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx>]

2013/8/14 Chris Morgan <chmorgan@xxxxxxxxx>

> <miguelangel@xxxxxxx> wrote:
> > (please use nbee/nbeepass as credentials)
> >
> > http://kicadhub.com/pcbs/2
> > http://kicadhub.com/assembly_guides/3
> > http://kicadhub.com/components/107
> > http://kicadhub.com/kicadnetlists/2
> >
> > But at this time I thought that my time was rather limited and that I was
> > better spending it at kicad itself, finishing and polishing what I
> started,
> > so I stopped it.
> >
>
> Interested in putting the server code out there so everyone can take a
> look at it?
>
> That's exactly my idea right now, but I must clean up, add license
headers, and put API keys into config files, and keep empty keys on the
repo itself.


>
> > Now if we mix my old idea, with this new approach:
> >
> > Everybody has his own github library repositories, and then we could
> build a
> > community aggregator, where you can add your git url, it keeps your parts
> > synced to the aggregator, it also keeps track of voting, pulls your
> library
> > updates, and builds an index/categorization that kicad can read,
> > then it re-exports on a single github repo (agreggated) and later,
> exports
> > an API (extension of the git idea) to keep track of votes, comments, etc.
> >
> > That aggregator might need a server (quite scalable as we relay
> fileserving
> > to github), but it must be fully open, same kicad license, so anybody
> could
> > build his own server if wanted (for example, within companies...)
> >
>
> Keep in mind that people may do unfortunate things to their github
> libraries, such as delete them, change parts etc. That's part of why I
> was thinking the server would want to store the data itself.
>
>
Yes, most probably would be a good idea keeping all versions of everything
on the exported git repo, this way you can always access the most popular
one or know derivatives. (derivative tracking can be handled on the server
db)


> The analogy I was thinking of was a pool of parts of varying ratings
> and authorship. The server could look to kicad as if it were a single
> github repository but could use user accounts to protect against the
> wrong people deleting/renaming parts.


They can delete/rename parts, but they become derivatives  with a parent
part, (just an idea)


> As the api is open there
> wouldn't be any issue if someone or some organization wanted to copy
> parts from one repository to another but imo if we had an official
> kicad blessed repository that might be the central go-to place that we
> could build into the plugin as a default source.
>



-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo