1.1. Fragmentation is bad, your fork is harmful!
I agree that fragmentation is bad. I believe the same aspects of
the current project management and especially the choice of VCS inevitably
leads to forks (just look at how many git forks are out there!). Such
fragmentation of developer and user resources may be bad for a project.
However, these decisions are not mine: the project is set up like
that, I can't change it
My fork is just a fork, just like any of the other forks. My fork happens to
be in an svn repository. I don't think it changes anything important from the
mainline's point of view.
1.2. ... but how will you get all these merged with mainline?
I won't. I haven't really used the official, current mainline since like
2011. I don't really care in what directions it evolves or whether it
takes features, code or ideas from pcb-rnd or not.
1.3. ... but you are in the best position for a merge!
I don't think so. I know my changes, but I don't know the changes happened
in the mainline since ages. I am also not efficient with git. It wouldn't
take me any less time than for mainline developers. Also please read point 1.2.:
I have no motivation in spending any time on a merge.
1.4. Ok then, but you won't have too many users.
Fine. My main intention was to produce a pcb editor for my own use. I am
happy if it's also useful for others, so I publish it. Having users
may increase code quality - but other than that, I don't get paid for having
more users, the project doesn't die if I code it alone, so I am not worried
about this.
Update (Aug 2016): an active user/contributor community is forming
around pcb-rnd. It is not a one-man-show anymore.
1.5. I'd like to merge something from pcb-rnd to mainline
Go ahead. I can help you by explaining my code. I won't generate
patches, make changes to get my code compatible with the mainline or
test how it performs in mainline versions.
1.6. I'd like to merge something from mainline to pcb-rnd
If the feature is in line with the goals of pcb-rnd, fine, I'll give
you svn commit access from day 0.
1.7. Would you abandon the development of pcb-rnd and join the mainline, if...
Unlikely. There are many things I have in pcb-rnd which I believe won't ever
happen in mainline. There are a few which I find critical: if I'd need to
give up any single item from this list, that would be a deal-breaker for me:
- simple, centralized VCS (not just the UI, the whole thing)
- VCS based, zero-administration release and publish interface
- a sane build system instead of autotools
- the code won't switch to C++
1.8. Would you join the development of gschem?
Unlikely. See point 1.7. Gschem is not aiming to a C++ transition AFAIK,
but has a lot of scheme. I don't consider joining or contributing to
gschem until those points listed in 1.7. are fixed and a new scheme
policy is introduced. The new policy should be: "from now on
do not write new code in scheme, use C; while making changes and fixes,
convert affected scheme code to C. Long term, explicit plan: convert all
scheme code to C and remove the guile dependency."
I don't expect any of this to happen.
Update (Aug 2016): Instead, I'll launch cschem .
2. git: did you know...
3.1. But I need opengl!
Use the mainline then. Or contribute the code for sane opengl support
in pcb-rnd.
Update (Aug 2016): GUI HIDs are plugins now, multiple GUIs can
be compiled and chosen run-time. Default GUI is a runtime configuration too.
All we need to have an opengl GUI HID now is a gl-capable volunteer.
Update (Mar 2017): thanks to our great contributors, the gl issue
is solved now - both gl and gdk rendering GTK hids are available now, for
runtime HID selection.
4. programming languages, file formats
4.1. switch to C++, it is so much better
Nope. I prefer C.
4.2. but pcb-rnd doesn't compile with a C++ compiled
Correct: pcb-rnd is written in C. It also doesn't compile with a Pascal
compiler.
4.3. but mainline already invested in preparing a C++ transition
Good for them. If I didn't have a fork, I'd fork the day when the first
C++ class is committed.
4.4. we need SQL for the file format
No, we don't. I prefer human readable text formats. No, converters won't
solve that. No, I don't care if python has support for loading SQL files.
Update (Aug 2016): the file format is a replaceable plugin now;
it's even possible to have multiple alternative formats active in the same
time. It's up to you to implement your format in a plugin.
4.3. we need to switch to xml/json (or python or perl arrays)
No, we don't need to.
Update (Aug 2016): ... unless you implement it in a plugin, see point 4.4.
4.4. ... but they are easier to parse because of existing libs
Yup, but in any real life task that part of the parsing is like 5%. The
rest 95% needs to be programmed anyway. The costs of such a file format change
is not justified by this minor gain.
4.5. ... but the current file format doesn't support feature X
True. And that's because the internal model (the in-core representation
and all the code handling that) doesn't support the feature either.
Changing the file format won't help that. It's similar to point 4.4.: 95%
of the effort is needed to get the code to support the feature, and by that
time the cost of getting it into the file format is very small. Costs
are not justified.
Update (Aug 2016): long term the new primary file format will be
lihata to overcome the above limitations. Later on the internal representation
may change too.
4.6. ... but I can't build a database of the current lib
Too bad. Either figure how to do it, or just don't do it. pcb-rnd
offers scripting, even in languages that have SQL support. In theory
it wouldn't be that hard to write scripts running in PCB manipulating
the buffer or even the in-core footprints on one end and connecting
an SQL database on the other end.
5. scconfig, autotools, build systems