1.1. Fragmentation is bad, your fork is harmful!
I agree that fragmentation is bad. I believe the some 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.
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.
2. git: did you know...