Mail Archives: geda-user/2015/12/22/22:36:56
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.
- Raw text -