Index: trunk/doc-rnd/devlog/20150830a_fork_faq.html =================================================================== --- trunk/doc-rnd/devlog/20150830a_fork_faq.html (revision 882) +++ trunk/doc-rnd/devlog/20150830a_fork_faq.html (revision 883) @@ -55,6 +55,18 @@ If the feature is in line with the goals of pcb-rnd, fine, I'll ive 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: + + +

2. git: did you know...

Preface: I don't try to convince you not to use git in your project; in @@ -68,19 +80,40 @@

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

+

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

+

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. I do not branch. I do not attempt to work offline for long, +whatever technical support the VCS may provide for that. I try to work in +a team, on a common code base. +

+I commit small things. I make sure I 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. +

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 multimillion 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!

@@ -141,8 +174,48 @@ 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 differnet internal model thus the UI differs +too. Same as vim has a differet 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 poeple 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. + +

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

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