pcb-rnd knowledge pool

 

Fork FAQ - why did the gEDA/PCB vs. pcb-rnd fork happen?

fork_faq by Tibor 'Igor2' Palinkas on 2015-08-30

Tags: insight, history, historic, fork, project, management, git, svn, vcs, version control

node source

 

 

Abstract: This document contains my short answers to questions commonly popping up in endless flamewars on the geda-user mailing list. Since pcb-rnd has left gEDA, this article is mainly kept for historical insight and explaining some of our design and project-management choices.

 

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.

1. Why did you fork?

1.1. Fragmentation is bad, your fork is harmful!

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.

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.

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.

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.

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.

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.

Update (Jan 2018): I decided to focus on pcb-rnd, so I don't spend time on active support on merging code to mainline.

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 No 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.

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 .

Update (2023): the first implementation of the cschem concept is called sch-rnd and has reached stable state in 2023.

2. git: did you know...

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.

2.1. ... that there was an svn frontend to git?

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.

2.2. ... that there was this great document about git?

See 2.1.

2.3. ... that DVCS is the future, anything centralized is bad, svn is obsolete?

These are not facts, but slogans I don't believe in.

2.4. What if someone has to develop offline for long?

In the 21th century, when we have cheap mobile internet even in eastern Europe?

2.5. But feature X is harder with svn!

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.

2.6. But there are no local repositories and you have to commit unfinished stuff and worry if anything breaks! And branching is hard

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.

2.7. But that's extra effort and makes life harder!

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.

2.8. I don't agree with any of this, git is better!

Cool, so go on using git. I didn't try to convince you not to, I just explained why I won't.

3. opengl

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.

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.

4.5. we need to switch to xml/json (or python or perl arrays)

No, we don't need to.

Update (Aug 2016): you may implement it as an optional format plugin, see point 4.4.

4.6. ... 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.

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.

4.7. ... 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.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.

4.8. ... 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-rnd 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

5.1. scconfig doesn't support feature X that autotools does

Are you sure? Maybe it does, just uses a different syntax. If not, did you try to send me a feature request?

5.2. scconfig's syntax is different

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.

5.3. But ./configure has to have the same UI as autotools

False.

5.4. Most people know autotools, there are merits in supporting the same features or UI

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.

5.5. But autotools is so much better!

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.

5.6. So why don't you rather fix autotools?

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.

5.7. But scconfig doesn't do cross compilation!

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.

5.8. I just don't like scconfig.

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.

6. What's with gEDA?

6.1. What's the relation between gEDA and pcb-rnd?

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.

6.2. Any plan to join 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.

6.3. So why don't you fix gEDA?

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.

6.4. What's the alternative to gEDA?

A more viable alternative is a coordinated ecosystem of actively developed projects. Ours is called CoralEDA .

Navigation

Search:

index nodes | all nodes | random node

Feedback

Report a bug or suggestion:

(Please include your email address in the description so I can answer)