Mail Archives: geda-user/2015/04/02/12:30:25
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--0-332061020-1427992205=:25799
Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
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 n=
ot
>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=
=20
repo.hu that does a lot of administration automtically, triggered by=20
simple svn commits I'd do normally. For example updating the web page on=20
a repo.hu project is commiting in the directory the project has configured=
=20
as web root.
By switching to gedasymbols.org I'd lose these features, so it is not=20
worth for me. Other users prefer DVCS (git or hg) and find CVS a constant=
=20
fight.
There is simply no one perfect solution that suits everyone. It's not=20
only how symbols/footprints are, this why we have different EDA tools,=20
libc implementations and operating systems out there. I find this valubale=
=20
as it provides more choices to the user.
>=C2=A0
> 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 sharpl=
y
>severable. Let me describe them separated:
>
>Problem: people don't find parts in the shipped library, so they create ne=
w
>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.=20
My opinion is that instead of trying to ship a huge library with all=20
components available, we should (by default) ship a small one that helps=20
the user learn the tool quickly then provide tools/methods that he can=20
download symbols/fps easily.
Drawbacks of one huge collection: just check the current stock lib: it's=20
eclectic. A lot of random "someone once needed this" parts. Beyond a=20
certain size, no matter how good your organization is, a beginner will get=
=20
scared of the sheer number of components he thinks he would never need.=20
Also, maintenance.... Let's face it: geda does not feature a dev group of=
=20
many people with lot of free time... If there's a small lib shipped, it=20
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=20
symbols/footprints should be distributed. It's one of the ways. I have=20
another way and perhaps other users have their ways too. Encouraging=20
people to share their stuff is a good idea. Encouraging them to use a=20
specific service you prefer is still okay. Not accepting that some people=
=20
find other services better is not that good.
Allowing people to have their choices ineviatbly leads to the=20
situation that there will be multiple different hosts serving different=20
libs - overlaps, gaps, redundancies, etc. This is not a problem or bug,=20
and we don't need to fix it.
There are things that can be made better, like how such random hosted=20
library chunks can be found, indexed, searched, or even collected and=20
distributed as a whole, if someone needs that.
Think of how free software and free operating systems work: noone says=20
all development must happen on a single source hosting service. People=20
host their software wherever, and users are free to roam and collect them.=
=20
Some people make large collections (Linux distributions or BSD variants=20
for example) and work hard to make all the random pieces work together.=20
Most end users will pick one of these collections instead of building=20
their own from scratch - without losing the ability to still do that, if=20
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.=C2=A0
Yes, as for the encouraging part: giving them access to a specific=20
service and making it easy for them to contribute is always good. Just=20
don't think everyone must or even should use the same service (or=20
software or brand - variety is a generic idea).
Regards,
Igor2
--0-332061020-1427992205=:25799--
- Raw text -