Index: trunk/doc-rnd/devlog/20150830a_fork_faq.html
===================================================================
--- trunk/doc-rnd/devlog/20150830a_fork_faq.html (nonexistent)
+++ trunk/doc-rnd/devlog/20150830a_fork_faq.html (revision 882)
@@ -0,0 +1,148 @@
+
+
+
+
+ Fork FAQ
+
+This document contains my short answers to questions commonly popping up
+in endless flamewars on the geda mailing list. The purpose of this
+document is not to convince anyone about any of the questions, only
+to save me typing the same answers when someone asks me
+one 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 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 ive
+you svn commit access from day 0.
+
+ 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?
+These are not facts, but slogens 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.
+
+
+ 3. opengl
+
+ 3.1. But I need opengl!
+Use the mainline then. Or contribute the code for sane opengl support
+in pcb-rnd. I can live with a solution where opengl is a separate HID and
+is not the default one.
+
+ 3.2. ... good, then please make that opengl hid!
+No, thanks. I don't need it, I wouldn't use it, there's no point in spending
+my time on it. If you need it, I invite you to do it.
+
+ 3.3. Did you know that opengl can be turned off in mainline?
+Yes. If I have a fork, I want its defaults to reflect my preferences.
+
+ 3.4. But transparent renders are so good on a board with many layers!
+Not for me: transparency made even a 2 layer board cryptic when I tried. See
+3.1.
+
+
+ 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 commited.
+
+ 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.
+
+ 4.3. we need to switch to xml/json (or python or perl arrays)
+No, we don't need to.
+
+ 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 neglible. Costs
+are not justufied.
+
+ 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 footpritns on one end and connecting
+an sql database on the other end.
+
+
+
+
+
+
+