kicad-developers team mailing list archive

[László Monda <laci@xxxxxxxx>]

I may be joining too late but having some ideas.

First of all let me just say that I'm in love with this concept.  I
consider GitHub to be the most robust and fertile software ecosystem
of our days.  Leveraging it could be hugely productive as opposed to
invent a whole new platform.  (I have no problems with new platforms
but the amount of work needed to create them is quite daunting.)

The core mindset of the ideas below is that as much as possible GitHub
could be used as the storage backend.  This comes pretty naturally to
me given my lack of desire to operate servers ;)

* There could be an (almost empty, skeleton) official KiCad library repository.

* Everyone wanting to be aggregated could fork this repository and
populate it with parts.

* The ranking of such aggregated repositories could be computed based
on the number of their stars and forks.

* Naturally, pull requests could be sent by others to fix parts.

On a somewhat related note I'm wondering why KiCad isn't hosted on
GitHub.  Given the popularity of GitHub it could give the project
better visibility and let's not even speak about the ultimate joy of
how easy it is to merge pull requests.

On Thu, Aug 15, 2013 at 5:27 PM, Miguel Angel Ajo Pelayo
<miguelangel@xxxxxxx> wrote:
>
> IMHO, RoR can be used to develop web apps faster (not faster web apps..),
> and has a wider community and library support, also has libraries to
> inteface ruby->python and make use of the kicad scripting wrappers.
>
> But that's just my opinion. Probably, if we get there at any time, it could
> make sense to define a common interface (REST?) and basic models, and then
> have a good server ecosystem instead of just one, then you connect your
> kicad to your favorite part servers.
>
>
>
>
> 2013/8/15 Chris Morgan <chmorgan@xxxxxxxxx>
>>
>> On Wed, Aug 14, 2013 at 6:29 AM, Miguel Angel Ajo Pelayo
>> <miguelangel@xxxxxxx> wrote:
>> >
>> > 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
>>
>>
>> Please let me know when/if you get this code out there so I can take a
>> look. In terms of implementation it might make sense to work with Joe
>> Ferner, the guy behind kicadcloud.com, since it looks like kicadcloud
>> is trying to do basically what we are trying to do.
>>
>> Chris
>
>
>
>
> --
>
> Miguel Angel Ajo Pelayo
> http://www.nbee.es
> +34 636 52 25 69
> skype: ajoajoajo
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>



-- 
László Monda <http://monda.hu>