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;
	bh=F0pwBGv64UpfMUaDGP9klbCYG7TzxCpLBcaCJ4NqesE=;
	b=UNsbhwzSfbx9KxyoIOSHz9hbo1Db3ytbuUY0s4thEz0sOrUYktZRai4HiJnY3GS8tV
	TNVGZOsGKPauTVyFUJwlf+HkSKuCxrVwCboEtR/aVxYVm3DgIgpLpyEjcppJzJQ3969h
	yFU8jL3jvjtxJ6YEC1BHSdywF3fF090yrA7rG4404KjGbzPZp7kdpRJ2AYrdZTRXpQ3p
	MkLjWqHWI9bgv+sZkxeDA9bMzwiP0+Bs3f7Bh7hTYBz0WVjNUUpR04COYDLQJYaBXMIN
	mQl4RkFzWyEk4vMH2QXHUqQt/Crqfifdc1Ud6WMz0QdzTgf4UwpirCBSMQLI0ZH938tn
	tncA==
MIME-Version:	1.0
X-Received:	by 10.112.209.4 with SMTP id mi4mr6165660lbc.7.1445448654413; Wed,
	21 Oct 2015 10:30:54 -0700 (PDT)
In-Reply-To:	<201510210954.46552.ad252@freeelectron.net>
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>
Date:	Wed, 21 Oct 2015 13:30:54 -0400
Message-ID:	<CAM2RGhTg=nT4aXqdiRz+OmHJ3WiMJntiTZyOH3AdFBZ8dEyT4w@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>
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

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.

>> 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.

> 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/

- Raw text -