X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Tue, 22 Dec 2015 22:12:45 -0500
From: "al davis (ad252 AT freeelectron DOT net) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] Project leadership
Message-ID: <20151222221245.303efe6b@floyd.freeelectron.net>
In-Reply-To: <20151222222341.8107.qmail@stuge.se>
References: <5AC3D5C5-144F-41AE-9562-47BC34D9047F AT noqsi DOT com>
 <CAJXU7q_GnuGNMtUWkB-xgBiKgY5R5W4ZCjtnz5EJizG+46dm1w AT mail DOT gmail DOT com>
 <C7FDF8B6-B335-46C3-8A25-F95ACECF4B79 AT noqsi DOT com>
 <CAJXU7q_3XwthnN_8mp7B+-ShHeK+=7J=54ZavKBUG3S3bSKp2A AT mail DOT gmail DOT com>
 <20151222193859 DOT 26898 DOT qmail AT stuge DOT se>
 <CAJXU7q_D7azR2ofhNwO4QggCf=bV6H0kZun6g5BExQQPLZyu_Q AT mail DOT gmail DOT com>
 <20151222224539 DOT 824d0603398b862d574e1ab4 AT gmail DOT com>
 <20151222222341 DOT 8107 DOT qmail AT stuge DOT se>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
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 Tue, 22 Dec 2015 23:23:41 +0100
"Peter Stuge (peter AT stuge DOT se) wrote:
> The thing here is that the project has to live with that contributed
> code for a very long time, and in my experience the developers who
> create those contributions tend not to accept ownership of them, but
> simply leave, handing their code over for others to maintain once the
> code is included into master.
> 
> If all contributions are accepted then the source code quickly
> becomes too heterogenous to be useful for further development.
> It becomes unmaintainable.
> 
> If only perfect contributions are accepted then the project as a
> whole evolves much more slowly - but IMO also much more surely.
>
> One of my worries is that the software we spend our lives working
> on degrades rather than improves. That would be a waste of our time.
> I want to avoid that dearly.

Or they make a fork, and the project goes two separate ways.

And you spend your life trying to reconcile incompatible forks, and
chase down the bugs left by those who did something quick then left.


This is a big part of the reasoning for Gnucap's plugin system.

Most of the code is in plugins.  There is a minimal core library that
is maintained to a high standard, with well established policies and
procedures for new work to be accepted into core.

For plugins, there is a separate git repository where new work and
unmoderated work goes.  If a new plugin is of sufficient quality and
usefulness, it could be distributed with core, but it remains a plugin.

All device models, commands, modeling functions, measurement devices,
netlist languages are plugins.

There are some "wrappers" to allow certain kinds of foreign code to be
used as plugins.  One of them is to allow Spice "C" models to be used
without modification as plugins.  If such a plugin is loaded at startup,
it can appear to be native.