File: ext_dont.html

package info (click to toggle)
pcb-rnd 3.1.7b-2
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid
  • size: 33,108 kB
  • sloc: ansic: 213,400; yacc: 6,241; sh: 4,698; awk: 3,016; makefile: 2,254; lex: 1,166; python: 519; xml: 261; lisp: 154; tcl: 67; perl: 34; javascript: 6; ruby: 5
file content (73 lines) | stat: -rw-r--r-- 4,220 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
<html>
<body>
<h1> pcb-rnd - plugin development - why not to create external plugins </h1>
<p>
Short answer: join us and create a core plugin instead. Or write a script in
one of the many scripting languages pcb-rnd supports.
<p>
Pcb-rnd has a fast paced, centralized development strategy, heavily building
on coordinated team work. There is no "API stability": we do not promise
that core APIs wouldn't change. But we do guarantee that any change to the
core will be immediately tracked in all core plugins.
<p>
The core team, by definition, will <b>not</b> consider or upgrade any
external plugin while changing core APIs. Scripts are much less affected
as they are using actions only and we try not to break action backward
compatibility.
<p>
Because of the high amount of development time goes into pcb-rnd these days,
if you start maintaining your own external plugin, you will need to spend
a portion of the time we spend on pcb-rnd on just keeping your plugin
from bit-rotting. Example in geda/PCB, with much slower core development, showed
that it does not pay back long term. There are usually four outcomes:
<ul>
	<li> You manage to keep up with core changes - but then you spend (waste) a
	     lot of time on just keeping your project up-to-date. You also have to
	     sync your release cycles to pcb-rnd's: users will have to pick the
	     corresponding plugin version for each pcb-rnd release else the plugin
	     won't work. That work could better be spent on developing the plugin
	     if it was a core plugin.
	<li> You support only one specific pcb-rnd version; this will get your plugin
	     unaccessible for most users as they will go on upgrading pcb-rnd.
	     Rationale: we probably spend more accumulated time on developing
	     pcb-rnd than you spend on developing your plugin, which means more
	     features and more bugfixes. Most users will sooner or later will choose
	     more activity over less. Also, users using pcb-rnd from packages
	     will be "forced" to upgrade by their distribution. So effectively
	     this leads to the 3rd possibility:
	<li> You maintain a plugin that practically will not be usable for
	     anybody else. Which sometimes leads to the 4th possibility:
	<li> Sometimes we import external plugins and start to maintain them as
	     core plugins. We had such a mass-import back in 2016, for bit-rotten
	     pcb plugins floating on the web. However, this could happen only with
	     abandoned plugins, as we are not going to keep merging forth and back.
	     Also, this method proven to be extremely inefficient: we already had
	     to rewrite 1/3 of the imported plugins, had to remove a few and
	     scheduled a full rewrite on another 1/3. This taught us that it's
	     often cheaper to write something from scratch than insisting on reuse.
	     We will especially refuse importing plugins that were started as external
	     plugin in order to overcome pcb-rnd conventions (e.g. svn or C89). So
	     if you can't accept our ways and can't join to do a core plugin, it
	     is not worth starting an external plugin effort and hope it will get
	     merged because there's high chance it will just bit-rot instead.
</ul>
<p>
That said, there are some legitimate cases when you could consider maintaining
an external plugin. For example if the goal of the plugin is so extremely
far away from pcb-rnd's that we do not accept the <b>idea</b> at all. But
if you start maintaining your plugin, and do not want to end up spending a lot
of time just to have something bit-rotting, you should really consider how much
time keeping things up to date will require, before you start.
<p>
Please also note that beause we really prefer our team work model, and we
most likely consider an external plugin effort just waste of time, we will
probably not endorse or promote your plugin in any way.
<p>
Please do <b>not</b> write an external plugin (or core plugin) off-svn and
then contact us to ask for inclusion as a core plugin. The only way a core
plugin can happen is that you contact the project lead, agree on some details,
get an svn write access and do it in pcb-rnd's repo. We will refuse to import
plugins developed differently.

</body>
</html>