Mail Archives: geda-user/2015/04/02/12:53:15
--047d7bdc11d61dbdf60512c0aa70
Content-Type: text/plain; charset=UTF-8
But you could just as easily say that trying to present the entire library
to a new user is chaotic. Hrm.
On Thu, Apr 2, 2015 at 12:41 PM, Russell 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, Apr 2, 2015 at 12:30 PM, <gedau AT igor2 DOT repo DOT hu> 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 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
>
>
>
--047d7bdc11d61dbdf60512c0aa70
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">But you could just as easily say that trying to present th=
e entire library to a new user is chaotic. Hrm.</div><div class=3D"gmail_ex=
tra"><br><div class=3D"gmail_quote">On Thu, Apr 2, 2015 at 12:41 PM, Russel=
l Nelson <span dir=3D"ltr"><<a href=3D"mailto:russnelson AT gmail DOT com" targ=
et=3D"_blank">russnelson AT gmail DOT com</a>></span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr">Anarchy doesn't mean chaos. It means *=
voluntary* organization. Encouraging chaos because you dislike hierarchy is=
simply the wrong way to go about it.</div><div class=3D"HOEnZb"><div class=
=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, A=
pr 2, 2015 at 12:30 PM, <span dir=3D"ltr"><<a href=3D"mailto:gedau AT igor=
2.repo.hu" target=3D"_blank">gedau AT igor2 DOT repo DOT hu</a>></span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex"><span><br>
<br>
On Thu, 2 Apr 2015, Russell Nelson wrote:<br>
<br>
</span><span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex">
On Thu, Apr 2, 2015 at 11:29 AM, <<a href=3D"mailto:gedau AT igor2 DOT repo DOT hu"=
target=3D"_blank">gedau AT igor2 DOT repo DOT hu</a>> wrote:<br>
<br>
BTW, all my symbols are GPL'd and are publicly accessible. It just<br>
happens that they are not hosted on <a href=3D"http://gedasymbols.org" targ=
et=3D"_blank">gedasymbols.org</a>.<br>
<br>
<br>
How might I find them? I could imagine a web page that has links to<br>
</blockquote>
<br></span>
Sure: svn://<a href=3D"http://repo.hu/openhw/projects/lib/trunk" target=3D"=
_blank">repo.hu/openhw/projects/<u></u>lib/trunk</a><br>
<br>
Feel free to link it from whatever symbol/fp directory page.<span><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
repositories, but ... why not just combine them all on gedasymbols? It'=
s not<br>
like you lose control or attribution.<br>
</blockquote>
<br></span>
It's that I prefer to use svn over cvs or git and I have a great system=
on <a href=3D"http://repo.hu" target=3D"_blank">repo.hu</a> 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 <a href=3D"http://repo.h=
u" target=3D"_blank">repo.hu</a> project is commiting in the directory the =
project has configured as web root.<br>
<br>
By switching to <a href=3D"http://gedasymbols.org" target=3D"_blank">gedasy=
mbols.org</a> 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.<br>
<br>
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.<span><br>
<br>
<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
=C2=A0<br>
=C2=A0 =C2=A0 =C2=A0What displeases me about your proposal is this: if I un=
derstood<br>
=C2=A0 =C2=A0 =C2=A0you correctly, gedasymbols would be an integral part of=
the<br>
=C2=A0 =C2=A0 =C2=A0tools. They would be coupled so tightly that I wouldn&#=
39;t have the<br>
=C2=A0 =C2=A0 =C2=A0option not to use <a href=3D"http://gedasymbols.org" ta=
rget=3D"_blank">gedasymbols.org</a>. I wouldn't have the option to<br>
=C2=A0 =C2=A0 =C2=A0maintain my own private or public libs hosted elsewhere=
under<br>
=C2=A0 =C2=A0 =C2=A0GPL or other license. I would be forced to license my l=
ibs under<br>
=C2=A0 =C2=A0 =C2=A0the GPL and automatically share them. It'd be unrea=
sonable and<br>
=C2=A0 =C2=A0 =C2=A0unacceptable restrictions on how I'd use a free sof=
tware. You<br>
=C2=A0 =C2=A0 =C2=A0would remove the ability that users can chose how to us=
e<br>
=C2=A0 =C2=A0 =C2=A0something because you believe you have a better way tha=
t should<br>
=C2=A0 =C2=A0 =C2=A0be forced on everyone.<br>
<br>
<br>
My bad! I shouldn't have combined those two ideas, because they are sha=
rply<br>
severable. Let me describe them separated:<br>
<br>
Problem: people don't find parts in the shipped library, so they create=
new<br>
parts that probably are already in gedasymbols.<br>
Solution: ship a copy of gedasymbols as the library and provide a way to<br=
>
keep it up to date.<br>
</blockquote>
<br></span>
Yup, that could work.<br>
<br>
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.<br>
<br>
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.<span><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
Problem: people create parts that aren't in gedasymbols, and don't<=
br>
contribute them back.<br>
</blockquote>
<br></span>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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).<span><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Solution: give them a public and a private symbol/fp folder. When they<br>
update gedasymbols, publish the public folder back to gedasymbols.=C2=A0<br=
>
</blockquote>
<br></span>
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).<br>
<br>
Regards,<br>
<br>
Igor2</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
--047d7bdc11d61dbdf60512c0aa70--
- Raw text -