On Thu, Apr 2, 2015 at 12:41 PM, Russel= l Nelson <russnelson AT gmail DOT com> wrote:

Anarchy doesn't mean chaos. It means *= voluntary* organization. Encouraging chaos because you dislike hierarchy is= simply the wrong way to go about it.

On Thu, A= pr 2, 2015 at 12:30 PM, <gedau AT igor2 DOT repo DOT hu> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

On Thu, 2 Apr 2015, Russell Nelson wrote:

On Thu, Apr 2, 2015 at 11:29 AM, <gedau AT igor2 DOT repo DOT hu> wrote:

BTW, all my symbols are GPL'd and are publicly accessible. It just
happens that they are not hosted on gedasymbols.org.

How might I find them? I could imagine a web page that has links to

Sure: svn://repo.hu/openhw/projects/lib/trunk

Feel free to link it from whatever symbol/fp directory page.

repositories, but ... why not just combine them all on gedasymbols? It'= s not
like you lose control or attribution.

It's that I prefer to use svn over cvs or git and I have a great system= on repo.hu that does a lo= t of administration automtically, triggered by simple svn commits I'd d= o normally. For example updating the web page on a repo.hu project is commiting in the directory the = project has configured as web root.

By switching to gedasy= mbols.org I'd lose these features, so it is not worth for me. Other= users prefer DVCS (git or hg) and find CVS a constant fight.

There is simply no one perfect solution that suits everyone. It's not o= nly how symbols/footprints are, this why we have different EDA tools, libc = implementations and operating systems out there. I find this valubale as it= provides more choices to the user.

=C2=A0
=C2=A0 =C2=A0 =C2=A0What displeases me about your proposal is this: if I un= derstood
=C2=A0 =C2=A0 =C2=A0you correctly, gedasymbols would be an integral part of= the
=C2=A0 =C2=A0 =C2=A0tools. They would be coupled so tightly that I wouldn&#= 39;t have the
=C2=A0 =C2=A0 =C2=A0option not to use gedasymbols.org. I wouldn't have the option to
=C2=A0 =C2=A0 =C2=A0maintain my own private or public libs hosted elsewhere= under
=C2=A0 =C2=A0 =C2=A0GPL or other license. I would be forced to license my l= ibs under
=C2=A0 =C2=A0 =C2=A0the GPL and automatically share them. It'd be unrea= sonable and
=C2=A0 =C2=A0 =C2=A0unacceptable restrictions on how I'd use a free sof= tware. You
=C2=A0 =C2=A0 =C2=A0would remove the ability that users can chose how to us= e
=C2=A0 =C2=A0 =C2=A0something because you believe you have a better way tha= t should
=C2=A0 =C2=A0 =C2=A0be forced on everyone.

My bad! I shouldn't have combined those two ideas, because they are sha= rply
severable. Let me describe them separated:

Problem: people don't find parts in the shipped library, so they create= new
parts that probably are already in gedasymbols.
Solution: ship a copy of gedasymbols as the library and provide a way to keep it up to date.

Yup, that could work.

We had a long discussion on this mailing list a few days ago about this. My= opinion is that instead of trying to ship a huge library with all componen= ts available, we should (by default) ship a small one that helps the user l= earn the tool quickly then provide tools/methods that he can download symbo= ls/fps easily.

Drawbacks of one huge collection: just check the current stock lib: it'= s eclectic. A lot of random "someone once needed this" parts. Bey= ond a certain size, no matter how good your organization is, a beginner wil= l get scared of the sheer number of components he thinks he would never nee= d. Also, maintenance.... Let's face it: geda does not feature a dev gro= up of many people with lot of free time... If there's a small lib shipp= ed, it has some chance to be maintained long term.

Problem: people create parts that aren't in gedasymbols, and don't<= br> contribute them back.

I don't find this a problem. Gedasymbols is not _the_ way symbols/footp= rints should be distributed. It's one of the ways. I have another way a= nd perhaps other users have their ways too. Encouraging people to share the= ir stuff is a good idea. Encouraging them to use a specific service you pre= fer is still okay. Not accepting that some people find other services bette= r is not that good.

Allowing people to have their choices ineviatbly leads to the situation tha= t there will be multiple different hosts serving different libs - overlaps,= gaps, redundancies, etc. This is not a problem or bug, and we don't ne= ed to fix it.

There are things that can be made better, like how such random hosted libra= ry chunks can be found, indexed, searched, or even collected and distribute= d as a whole, if someone needs that.

Think of how free software and free operating systems work: noone says all = development must happen on a single source hosting service. People host the= ir software wherever, and users are free to roam and collect them. Some peo= ple make large collections (Linux distributions or BSD variants for example= ) and work hard to make all the random pieces work together. Most end users= will pick one of these collections instead of building their own from scra= tch - without losing the ability to still do that, if they want (this is ho= w new distributions start).

Solution: give them a public and a private symbol/fp folder. When they
update gedasymbols, publish the public folder back to gedasymbols.=C2=A0

Yes, as for the encouraging part: giving them access to a specific service = and making it easy for them to contribute is always good. Just don't th= ink everyone must or even should use the same service (or software or brand= - variety is a generic idea).

Regards,

Igor2