X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=PXVN9H2Mn2gpmd0ygqyNH7Pwhnpsnb0JP2kTqePIMc4=; b=BIEzVsEW7O8yrannBgoFKn4Ru8z7pK5ac8bYJKQXBgQzGH5GTcUUCVe0lMTcVDONXn 4obegdA+4t8N6awbhDvGKJSE7ld94Amv+6xooLSnkB5sVjScH+YdErVeVHGHa8UZOsbT 1V5nI12FF7WnS7bwhPng6ZWj9DwfPxs8RyJzyzEVdCZK6OL6TQsgQpP9XHRioMqKyVff MzcBPBLi3W3IwKvUkMMvlH56E8A6gMrC81K+WiJ++1XDWzijf9D8woI5aAHxSh8/8hRu /hmUaKg2uyJJ478G4giUTty5fDOJ5vTpWaqXsUckcUT6ZAGND/4cIYy2sTLSyZLyl6cz 1wQQ== MIME-Version: 1.0 X-Received: by 10.107.169.35 with SMTP id s35mr72807586ioe.46.1427992867671; Thu, 02 Apr 2015 09:41:07 -0700 (PDT) In-Reply-To: References: <1427905808 DOT 32608 DOT 60 DOT camel AT benjamin-hp-g70> <20150401214846 DOT 5d2261e6 AT jive> <201504011954 DOT t31JsnKh020289 AT envy DOT delorie DOT com> <20150401221210 DOT 1b4a299e AT jive> <201504012014 DOT t31KEq1m020861 AT envy DOT delorie DOT com> <551C574F DOT 2030708 AT xs4all DOT nl> Date: Thu, 2 Apr 2015 12:41:07 -0400 Message-ID: Subject: Re: [geda-user] PCB and gschem libraries From: Russell Nelson To: geda-user AT delorie DOT com Content-Type: multipart/alternative; boundary=001a114214709e94860512c07f81 Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk --001a114214709e94860512c07f81 Content-Type: text/plain; charset=UTF-8 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, Apr 2, 2015 at 12:30 PM, wrote: > > > On Thu, 2 Apr 2015, Russell Nelson wrote: > > On Thu, Apr 2, 2015 at 11:29 AM, 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 lot of administration automtically, triggered by > simple svn commits I'd do 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 gedasymbols.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 only > 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. > > > > >> What displeases me about your proposal is this: if I understood >> you correctly, gedasymbols would be an integral part of the >> tools. They would be coupled so tightly that I wouldn't have the >> option not to use gedasymbols.org. I wouldn't have the option to >> maintain my own private or public libs hosted elsewhere under >> GPL or other license. I would be forced to license my libs under >> the GPL and automatically share them. It'd be unreasonable and >> unacceptable restrictions on how I'd use a free software. You >> would remove the ability that users can chose how to use >> something because you believe you have a better way that should >> be forced on everyone. >> >> >> My bad! I shouldn't have combined those two ideas, because they are >> sharply >> 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 > components available, we should (by default) ship a small one that helps > the user learn the tool quickly then provide tools/methods that he can > download symbols/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. Beyond a > certain size, no matter how good your organization is, a beginner will get > scared of the sheer number of components he thinks he would never need. > Also, maintenance.... Let's face it: geda does not feature a dev group of > many people with lot of free time... If there's a small lib shipped, it has > some chance to be maintained long term. > > >> Problem: people create parts that aren't in gedasymbols, and don't >> contribute them back. >> > > I don't find this a problem. Gedasymbols is not _the_ way > symbols/footprints should be distributed. It's one of the ways. I have > another way and perhaps other users have their ways too. Encouraging people > to share their stuff is a good idea. Encouraging them to use a specific > service you prefer is still okay. Not accepting that some people find other > services better is not that good. > > Allowing people to have their choices ineviatbly leads to the situation > that there will be multiple different hosts serving different libs - > overlaps, gaps, redundancies, etc. This is not a problem or bug, and we > don't need to fix it. > > There are things that can be made better, like how such random hosted > library chunks can be found, indexed, searched, or even collected and > distributed 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 > their software wherever, and users are free to roam and collect them. Some > people 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 scratch - without losing the ability to still do that, if they want > (this is how 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. >> > > 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 think > everyone must or even should use the same service (or software or brand - > variety is a generic idea). > > Regards, > > Igor2 --001a114214709e94860512c07f81 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Anarchy doesn't mean chaos. It means *voluntary* organ= ization. Encouraging chaos because you dislike hierarchy is simply the wron= g way to go about it.

On Thu, Apr 2, 2015 at 12:30 PM, <gedau AT igor2 DOT repo DOT hu&g= t; wrote:


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

--001a114214709e94860512c07f81--