NOTE: This document is somewhat obsolete. It was written back when pcb-rnd was still around gEDA, answering the questions coming from gEDA users. In the past years we have cut every tie to gEDA, our new users are typically coming from elsewhere so this node is of historical interest only.
WARNING: The purpose of this document is not to convince anyone about any of the questions, only to save me some time typing the same answers when someone asks me one of these questions for the 100th time. As I don't want to convince you that my answers are the best ones, please don't try to convince me that they are bad. Been there, done that, never worked in either way: e.g. I never convinced any git fanboy to switch to svn, and they never convince me to switch to git.
I agree that fragmentation is bad. I believe the same aspects of [their] 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.
Update (Jan 2018): pcb-rnd has left gEDA. We have replaced and/or heavily edited more than 2/3 of the code base. We have fixed decade old design errors and bugs and implemented features gEDA/PCB probably won't have any time soon. We've also built a new community, a more constructive and productive and friendly one. Pcb-rnd sky-rocketed, while gEDA stood still. We have proven on every level, with every objectively measured parameter that pcb-rnd is more vital. We started to walk separate ways in 2013. From our perspective we did bring the project to the next level while mainline didn't do much in 2017. By now the fork is not us, but gEDA/PCB - so the real question is not why we did deviate, but why do they keep on deviating.
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.
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.
Update (Jan 2018): As discussed in 1.1, the question is different: not why we don't merge our changes in a dead project, rather why don't they abandon pcb and join pcb-rnd instead, trying to merge their changes in a live project.
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.
Update (Jan 2018): by now, the pcb-rnd community is at least a magnitude more active than the pcb community - we did get many users. Those who care about getting things done.
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.
Update (Jan 2018):I decided to focus on pcb-rnd, so I don't spend time on active support on merging code to mainline.
If the feature is in line with the goals of pcb-rnd, fine, I'll give you svn commit access from day 0.
UnlikelyNo way. 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:
Update (Jan 2018): by now it's rather no way. The above list has been extended with a proper file format, proper data model and a proper community.
Update (Apr 2019): check out my short summary on why any kind of collaboration with gEDA turned out to be impossible.
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 .
Update (2023): the first implementation of the cschem concept is called sch-rnd and has reached stable state in 2023.
Preface: I don't try to convince you not to use git in your project; in return, please don't try to convince me I should use git in mine.
Yes. 2/3 of my problems with git and DVCS in general are not of technical nature. I know the concepts of DVCS and I find them suboptimal in case of small teams. A different UI or a good document won't help in that.
See 2.1.
These are not facts, but slogans I don't believe in.
In the 21th century, when we have cheap mobile internet even in eastern Europe?
Almost all those features are bad for team work in my experience. They are not even needed. Yes, some aspects of the development have to be done differently without those - but this is good for the project.
This is the point. We do not branch. We do not attempt to work offline for long, whatever technical support the VCS may provide for that. We try to work in a team, on a common code base.
We commit small things. We make sure we do a big transition using these small commits in a way that the code stays compilable in between any two commits. It rarely breaks trunk/ for longer than a few minutes. I need a real branch once a decade.
Update (Jan 2018): for example we managed to replace the whole data model while users did work on production boards with latest svn checkouts, even using some of the latest new data model features.
Yes and no. It's certainly harder to design and carry out a big reorganization in small steps. This is an extra cost. However, the benefits outweight this: everyone working in the same repo, other developers see and comment what you are working on, if done right, merging is nearly never needed and conflicts are as rare as bugfree release of a multi-million line proprietary software.
Cool, so go on using git. I didn't try to convince you not to, I just explained why I won't.
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.
Nope. I prefer C.
Correct: pcb-rnd is written in C. It also doesn't compile with a Pascal compiler.
Good for them. If I didn't have a fork, I'd fork the day when the first C++ class is committed.
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.
Update (Jan 2018): by now we have a bit more than a year of experience with our new, lihata based native file format. The transition went well, production users didn't feel much disruptions. The new file format can keep up with the data model replacement.
No, we don't need to.
Update (Aug 2016): you may implement it as an optional format plugin, see point 4.4.
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.
Lihata, our native file format, is also easy to parse and has an existing library. The API is small, just write a binding to your favorite language if needed.
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.6.: 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.
Update (Jan 2018): meanwhile the new file format did happen and we started the data model transition. As expected, the data model rewrite took about 8x more time than the file format transition. We have removed the old model completely. Now we have both a proper data model and a proper file format while kept pcb-rnd usable and testable for the whole transition. And we also kept compatbility.
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-rnd manipulating the buffer or even the in-core footprints on one end and connecting an SQL database on the other end.
Are you sure? Maybe it does, just uses a different syntax. If not, did you try to send me a feature request?
Yes. Scconfig has a totally different internal model thus the UI differs too. Same as vim has a different UI than emacs, while they are both text editors and the two communities are not trying too hard to unify the UIs.
False.
I do realize that. I've been working on scconfig since 2008. I've invested a lot of time in it. Believe me, I did think it over before I decided that the benefits would overweight the drawbacks of developing/using a custom config/build system.
No, it isn't. My experience is that with random open source projects on anything different from Linux, modern BSD, and sometimes windows, it just breaks at least 8 times out of 10. Try it once on IRIX or minix.
Update (Jan 2018): as of now, we have years of intense, daily user testing in the build system. Almost every single feedback is positive. Most feedbacks do acknowledge how much simpler and better our configuration/build is compared to autotools. Time has proven my point on this.
I believe there are multiple design problems in autotools and most of the practical problems I faced when using it were directly caused by those. In a sense, I did fix these design problems by using a different design. The different design is called scconfig and it was much easier to write it from scratch.
False. It does. It's been supported since May 2008. It's been added about 1.5 months after the very first file.
Update (Aug 2016): as a practical example, windows .exe has been cross-compiled on a Linux box.
If you have something particular that makes you dislike scconfig, a missing feature for example, please let me know.
Else maybe you don't like using anything else than autotools. It's your choice; mine is that I do keep on using scconfig in my projects.
None, or at most only historical: we still have like ~20% code that looks similar to gEDA/PCB's, but other than that:
So all in all, pcb-rnd is fully independent of gEDA.
Nope. gEDA is going in a direction that's suboptimal for pcb-rnd. If gEDA is goign anywhere at all... Joining a stalled effort wouldn't be a good idea for a fast moving project like pcb-rnd.
It can not be fixed. I've tried, I've failed. After years of mailing I figure gEDA lead and individual gEDA project leaders just prefer to keep gEDA this way.
Check out my short summary on why it is impossible to fix gEDA.
A more viable alternative is a coordinated ecosystem of actively developed projects. Ours is called CoralEDA.