X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Original-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:content-transfer-encoding;
        bh=XhccpZtEZrvsUf8sC9g3y+ESdHpoJGOnK59juAggZ1c=;
        b=yF1DsaFWhR3/WP/RAzUEJDGjzAFBFG8dlQ1BfPsDoxTW9LO0x5SRqhoUSmNL5H+Cf0
         5+JA9nUjGDG6CVKLL+2yucI8t1Lla0N4Btw7WRxmpvqqg+0B6S/GS3/Qhgr3kYyoBvMh
         h8R/R/XCqA8UZg5e9XL4aPoov3oS0P1GeL2IDk1pP9H5C9P0XBnCVSSwl1sCAfCYbame
         EM0T6gwKIJ/U0oPkgfI5rB32hUO27OrxVTtrwpXG4VULuwwoTmW4FNwEFd7fZDYBkQWP
         hMD5YIh1DYZLxJBsxg5OHQugcf04bB0q5lZRC10ZLEfWvgr2bD6QE6FSvgMeBXopWyY0
         cxHw==
MIME-Version: 1.0
X-Received: by 10.25.205.193 with SMTP id d184mr1886081lfg.72.1445452903693;
 Wed, 21 Oct 2015 11:41:43 -0700 (PDT)
In-Reply-To: <DA7D969B-6516-4633-831C-FFADA38E1807@noqsi.com>
References: <1042003D-82E2-40F0-AB60-8186580C46AD AT noqsi DOT com>
	<34B17816-9EA5-45FD-BFB4-9D623A8D3D87 AT noqsi DOT com>
	<CAM2RGhR+K+dvDdXsbk0Y6LN=-7RhhG5wvtG4i0k4+uMgzd=H0w AT mail DOT gmail DOT com>
	<201510210954 DOT 46552 DOT ad252 AT freeelectron DOT net>
	<CAM2RGhTg=nT4aXqdiRz+OmHJ3WiMJntiTZyOH3AdFBZ8dEyT4w AT mail DOT gmail DOT com>
	<DA7D969B-6516-4633-831C-FFADA38E1807 AT noqsi DOT com>
Date: Wed, 21 Oct 2015 14:41:43 -0400
Message-ID: <CAM2RGhRN5S1KZCNFQwoVTPg3=mC5xrK2z9XTOpWwPuF0iVS+Rg@mail.gmail.com>
Subject: Re: [geda-user] A lesson from gnet-makefile
From: "Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: gEDA users mailing list <geda-user AT delorie DOT com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id t9LIfnu2010802
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

On Wed, Oct 21, 2015 at 1:54 PM, John Doty <jpd AT noqsi DOT com> wrote:
>
> On Oct 21, 2015, at 11:30 AM, Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
>
>> On Wed, Oct 21, 2015 at 9:54 AM, al davis (ad252 AT freeelectron DOT net)
>> [via geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
>>> On Tuesday 13 October 2015, Evan Foss (evanfoss AT gmail DOT com) [via
>>> geda-user AT delorie DOT com] wrote:
>>>> We could prototype it via a plugin but in the long term it
>>>> should really be in the core.
>>>
>>> Maybe, but maybe you should rethink  plugins.
>>>
>>> Gnucap takes the approach of putting as much as possible in
>>> plugins.  Anything that can be a plugin is required to be a
>>> plugin.  A set of plugins is distributed with core, but they are
>>> still plugins.
>>
>> While I agree the fact is that this change will make possible a whole
>> family of plugins that will use it. That is half the justification for
>> putting it in the core. The other half is that the same functionality
>> for handling flattened nets is also in the core for the same reason so
>> splitting their locations would be architecturally confusing to new
>> people.
>
> But the first problem is understanding which functions should be in the core. That requires understanding the FFI and the Scheme functions built atop it.

I am not indulging in another hunt for the snark with you on this.

>>
>>>> To be honest I find your
>>>> "don't touch the core you will break something" attitude
>>>> kind of insulting.
>>>
>>> Don't touch core if you can do it in a plugin is good policy,
>>> but core needs to develop too.
>>
>> John's fear (which he later admitted was miss placed in this
>> situation) was over someone making changes that required updating all
>> gnetlist backends.
>
> Not simply that. A change that broke just one back end might actually be harder to deal with. And a change that couldn’t be undone in a back end would be very bad.

The only changes that can not be undone are too user expectations.
We need a regression testing suite for the gnetlist backends. What
also needs to happen is added documentation of all the workflows we
support so that a list of what a user/developer can expect is made.

* Every list of connected pins can have a netname but it is not required.
* A list of connections can only have one netname.
* Using the same netname twice with out showing a visual connection
still creates a valid connection.
* Every pin has to have a pinnumber.
* Pins may not have duplicate numbers.

I assume there is little if any vagueness left in the backend documentation.

>>
>>> There needs to be some discipline in how core changes are done.
>>> Having a bunch of developers all messing with "master" leads to
>>> a big mess.
>>
>> 1. No one was considering doing that. They just rolled out a package
>> server side for managing a hierarchy of user accounts.
>> 2. I intentionally opted out of having commit privileges to the master
>> so someone else will have to approve it.
>>
>>> In Gnucap, all work on core is done in branches.  A branch is
>>> considered ready to merge when it is shown to work correctly,
>>> has test cases, is formatted correctly, announced and discussed
>>> on the developer list, and its branch can be merged to master or
>>> unstable as a fast-forward merge.  When ready, the branch is
>>> pushed to unstable for final review and then to master after a
>>> few weeks.  So, master is always "considered stable".
>>
>> How branches are managed is a matter of some debate but I am not
>> involved in that.
>>
>>
>> --
>> Home
>> http://evanfoss.googlepages.com/
>> Work
>> http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/
>>
>
> John Doty              Noqsi Aerospace, Ltd.
> http://www.noqsi.com/
> jpd AT noqsi DOT com
>
>



-- 
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/