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=TAhCPF0q0uWfVkuj3ACpFDQBi+VZxmY4tcf0/jP3oF4=;
	b=xgVUsZkX+et+TAbDai7x00mKwMCI1sbGxgXx3WzfypNH+vp8aVZo6kVhfxFxppxTsq
	nD5zwSIk2ejG17rm2NK73H+u25hqOwHADheIgTqLrCum6EROqXr5QXkPvpL1jqc65OJ2
	81qsxezyK1Nf9VhvF3WBcnn/7T5/P7hrtR7RxKyAixiSyK1DpzGClT2umQR6oXMWRRbW
	YxfjzjW4KBBP6jp/1voBXIG8PWS+GKraKpjLMk00+S6BsrOynmNO+EcZLYyKEGJp7tce
	8zo40lQQOaqQKjgVq4CpyW6E0h628628dUM4gnwXYNbALtqDaNgNg9jqj5AtOYyr4XUr
	ubpw==
MIME-Version:	1.0
X-Received:	by 10.181.13.82 with SMTP id ew18mr3485417wid.22.1394550727395;
	Tue, 11 Mar 2014 08:12:07 -0700 (PDT)
In-Reply-To:	<CAG4ve9L-HKjGH3SZ4UFHfQPonkvxJbGoqpnQnxAmcurNaFuRaQ@mail.gmail.com>
References:	<CAG4ve9LgHNoVZoGaGgF67tadJ_n=L6Uy1g=UPPrkM0fL6Rgufw AT mail DOT gmail DOT com>
	<20140127234944 DOT 924148045B78 AT turkos DOT aspodata DOT se>
	<CAG4ve9+3jhFJ1Cr6CLUyLX_y02uigJECiUCwxjUWdP=heVocqg AT mail DOT gmail DOT com>
	<20140128201110 DOT DF7D78045B78 AT turkos DOT aspodata DOT se>
	<20140129072550 DOT GA24560 AT localhost DOT localdomain>
	<CAG4ve9+v9QxNRaPSFkmGfr6bKsv7km-Gt_gwXF7Eh4TX+AmNug AT mail DOT gmail DOT com>
	<CAOP4iL2JBUdF93kZF-iQ9Rv+VTN3iXoT+6C4LoBi5qaMxof=sA AT mail DOT gmail DOT com>
	<CAG4ve9+QsUf=nVXPe-f3VddGiqHn8sjZUJNkdu3QV1cOQDWiAg AT mail DOT gmail DOT com>
	<20140309173951 DOT 738798020179 AT turkos DOT aspodata DOT se>
	<531CF3BE DOT 8070407 AT ecosensory DOT com>
	<CAG4ve9LKJS1RxPZxUdOSwFifQXoVJtJMOV=7PMs2vrjf70L1KQ AT mail DOT gmail DOT com>
	<CAOP4iL3mQJjH_2gOZ1E=POzpiLuJKTxOu_FN7UD-=BfV6BOQ1w AT mail DOT gmail DOT com>
	<CAG4ve9L-HKjGH3SZ4UFHfQPonkvxJbGoqpnQnxAmcurNaFuRaQ AT mail DOT gmail DOT com>
Date:	Tue, 11 Mar 2014 08:12:07 -0700
Message-ID:	<CAOP4iL1d0WQ5x65NfiXoR3uHGP8Hm8uUKS8n_gWSGsFrY6JSMA@mail.gmail.com>
Subject:	Re: [geda-user] identical symbol names
From:	Ouabache Designworks <z3qmtr45 AT gmail DOT com>
To:	geda-user AT delorie DOT com
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

--f46d043c7cccbaccfe04f45624bd
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 11, 2014 at 6:18 AM, =E1=CC=C5=CB=D3=C5=CA =E8=C1=D2=D8=CB=CF=
=D7=D3=CB=C9=CA
<svetonomer AT gmail DOT com>wrote:

>
> "The Pragmatic Programmer" was written by two guys with lots of experienc=
e
>> in real world firmware design. A lot of the book also applies to  Hardwa=
re
>> design. One thing that they stress through out the book is to NEVER copy
>> any data in your database.
>>
> Most commercial programs for pcb design copy library components in the
> project files.
>
> An organisation like gEDA  should keep all libraries under a revision
>> control system that anyone can check out.
>>
> Users have the right to keep their own components and not include them in
> any repository.
> Not all users have Geda gedasymbols account due to obvious reasons.
>
>> Then you can easily check for updates and revisions.
>>
> And do it all manually.
> And if suddenly the updated components create bugs in the old schemas nee=
d
> to manually roll back, and then stored in directories with these old
> schemas. So you come to my version.
>
>

A lot of designers do make copies of things all the time. A lot of
commercial projects run into problems.  Some designers have traced the root
cause of these problems back to somebody using the wrong copy of something.
That is why we want you to stop making copies, you are making our jobs
harder.

Everybody MUST keep their components in a repository. We call that "keeping
a backup". It does not have to be on the internet and visible to the world.
My personal backups are a monthly dump to dvd and stored it in the barn in
case the house burns down. If you work for a company then you may  work on
a local copy of your files on your workstation but the "official" copy will
be kept by the company in their repositories. You will make frequent (ie:
weekly or even daily) check ins so that your latest work is always stored
in a repository. That's how the pros do it.

Updating components do not break old designs. Once a component is released
and used in production then you cannot make any material changes to that
component. You can however create a new revision of that component and
release that one with a different version number. When a user does an
update then they will see that there are new versions and can decide to
stay with the old or replace it with the new. Nothing breaks unless the
user takes action. If something does break then they can back out by
deleting any changed file and restoring them from the repository.

Now during the early development  phase before anything is released there
is a chaotic period where everyone is making changes without doing an
official new versions and  things are breaking every day. You simply have
to warn the other designers and hope it settles down quickly.

Besides versions there is a concept called variants. In IC design you want
to create components that are flexible so the end user can customize them
to their exact needs. We do this using parameters. But parameters do not
work in two cases, they cannot modify a port list or a file list. These
require variants.

If you have a cpu with the option of having a debugger interface then you
cannot select this with a parameter. The debugger will have io ports that
don't exist on a non-debugged cpu. So you will release two variants, one
with debugger ports and one without.


John Eaton

--f46d043c7cccbaccfe04f45624bd
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Tue, Mar 11, 2014 at 6:18 AM, =E1=CC=C5=CB=D3=C5=CA =E8=C1=D2=D8=
=CB=CF=D7=D3=CB=C9=CA <span dir=3D"ltr">&lt;<a href=3D"mailto:svetonomer AT gm=
ail.com" target=3D"_blank">svetonomer AT gmail DOT com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote"><div class=3D""><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">
<div dir=3D"ltr"><div><div>&quot;The Pragmatic Programmer&quot; was written=
 by two guys with lots of experience in real world firmware design. A lot o=
f the book also applies to=9A Hardware design. One thing that they stress t=
hrough out the book is to NEVER copy any data in your database.</div>

</div></div></blockquote></div><div><span lang=3D"en"><span>Most commercial=
</span> <span>programs</span> <span>for</span> <span>pcb</span> design <spa=
n>copy</span> <span>library components</span> <span>in</span> <span>the pro=
ject files</span><span>.</span></span>
<br><br></div><div class=3D""><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex"><div dir=3D"ltr"><div>An organisation like gEDA=9A should keep all lib=
raries under a revision control system that anyone can check out. </div>

</div></blockquote></div><div><span lang=3D"en"><span>Users have the right<=
/span> <span>to keep their</span> <span>own components</span> <span>and</sp=
an> <span>not include them</span> <span>in any</span> <span>repository.<br>

</span></span><span lang=3D"en"><span>Not all users</span> <span>have</span=
> <span>Geda</span> <span>gedasymbols</span> <span>account</span> <span>due=
 to</span> <span>obvious reasons.<br>
</span></span></div><div class=3D""><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr"><div>Then you can easily check for updates and =
revisions.</div>
</div>
</blockquote></div><div><span lang=3D"en"><span>And do it</span> <span>all<=
/span> <span>manually.</span> <br><span>And if suddenly</span> <span>the up=
dated components</span> <span>create</span> <span>bugs in the old</span> <s=
pan>schemas</span> <span>need to</span> <span>manually</span> <span>roll ba=
ck</span><span>, and then</span> <span>stored in</span> <span>directories</=
span> <span>with these old schemas</span><span>.</span> <span>So you</span>=
 <span>come to my</span> <span>version.</span></span></div>

<br></div></div></div>
</blockquote></div><br><br></div><div class=3D"gmail_extra">A lot of design=
ers do make copies of things all the time. A lot of commercial projects run=
 into problems.=9A Some designers have traced the root cause of these probl=
ems back to somebody using the wrong copy of something. That is why we want=
 you to stop making copies, you are making our jobs harder.<br>
<br></div><div class=3D"gmail_extra">Everybody MUST keep their components i=
n a repository. We call that &quot;keeping a backup&quot;. It does not have=
 to be on the internet and visible to the world. My personal backups are a =
monthly dump to dvd and stored it in the barn in case the house burns down.=
 If you work for a company then you may=9A work on a local copy of your fil=
es on your workstation but the &quot;official&quot; copy will be kept by th=
e company in their repositories. You will make frequent (ie: weekly or even=
 daily) check ins so that your latest work is always stored in a repository=
. That&#39;s how the pros do it.<br>
<br></div><div class=3D"gmail_extra">Updating components do not break old d=
esigns. Once a component is released and used in production then you cannot=
 make any material changes to that component. You can however create a new =
revision of that component and release that one with a different version nu=
mber. When a user does an update then they will see that there are new vers=
ions and can decide to stay with the old or replace it with the new. Nothin=
g breaks unless the user takes action. If something does break then they ca=
n back out by deleting any changed file and restoring them from the reposit=
ory.<br>
<br></div><div class=3D"gmail_extra">Now during the early development=9A ph=
ase before anything is released there is a chaotic period where everyone is=
 making changes without doing an official new versions and=9A things are br=
eaking every day. You simply have to warn the other designers and hope it s=
ettles down quickly.<br>
<br></div><div class=3D"gmail_extra">Besides versions there is a concept ca=
lled variants. In IC design you want to create components that are flexible=
 so the end user can customize them to their exact needs. We do this using =
parameters. But parameters do not work in two cases, they cannot modify a p=
ort list or a file list. These require variants. <br>
<br></div><div class=3D"gmail_extra">If you have a cpu with the option of h=
aving a debugger interface then you cannot select this with a parameter. Th=
e debugger will have io ports that don&#39;t exist on a non-debugged cpu. S=
o you will release two variants, one with debugger ports and one without.<b=
r>
<br><br></div><div class=3D"gmail_extra">John Eaton<br>=9A<br></div><div cl=
ass=3D"gmail_extra"><br><br><br><br><br><br><br></div><div class=3D"gmail_e=
xtra">=9A <br></div><div class=3D"gmail_extra"><br><br></div></div>

--f46d043c7cccbaccfe04f45624bd--

- Raw text -