Index: trunk/doc-rnd/index.html =================================================================== --- trunk/doc-rnd/index.html (revision 39) +++ trunk/doc-rnd/index.html (revision 40) @@ -6,6 +6,15 @@ I don't plan to submit these patches or merge changes from the official repo (motivation).

+Feel free to give it a try: +

+ +

List of major changes:
commit message tag and docdescription Index: trunk/doc-rnd/motivation.html =================================================================== --- trunk/doc-rnd/motivation.html (nonexistent) +++ trunk/doc-rnd/motivation.html (revision 40) @@ -0,0 +1,54 @@ + + +

pcb-rnd motivation

+I use PCB a lot on various computers. I used to try to join the mainstream +development with small contribution (minor patches) and was active on +IRC and the mailing lists for a while. However, it didn't work out well, +and: +
    +
  • PCB already knew 95% of everything I'd ever need years ago +
  • the remaining 5% was not on the TODO list of developers and generally no one shown much interest in getting patches for those +
  • meanwhile a lot of new features have been added, from which most I find totally useless: +
      +
    • dbus +
    • gl - transparency makes even simple 2 sided boards unusable; slower than the classic version sw render on all my computers +
    • preparation for a C++ transition +
    +
  • the official Debian package enables (requires, depends on) both dbus and gl +
  • DVCS - it almost always results in chaos, and has no benefit for such a small group of developers; there are posts from time to time on the mailing list about how to handle the chaos; my choice is to stick with a simple, centralized version control system +
  • DVCS always results in increased administration, which I hate to spend my time on - I'd rather invest the time in bugfixing, documentation or implementing new features +
  • it's nearly impossible to get small patches applied: +
      +
    • often no one has the time to revise and commit them +
    • communication requires web2.0 +
    • there are too many cycles of "please fix this and change that first" +
    • with the chaos VCS, it's too likely that new feature patches would require ongoing maintenance to avoid that a large scale merge (or rebase, whatever) of another feature branch breaks it +
    +
  • I don't even dream about getting larger patches +
  • no stable release for years; can't maintain a set of patches (like pcb-gpmi) and port them to new releases +
+I was pondering a for for years. The trigger was that one day I've upgraded +Debian on my lab computer and the new version of PCB came with gl enabled; this +made PCB absolutely unusable (had to wait like 10 seconds for a scroll) while +all the transparent polys over traces made the whole screen a mess. I should +have recompiled everything and built a new Debian package with gl disabled or +install from source (but I have too many computers for that). My decision +was to set up my own .deb but then build it from a fork (it's not much of +an extra effort), so I can add some of the features I miss in daily use. +My plans with this fork: +
    +
  • I will stick with my fork and will use it on all my computers for all my designs +
  • Because of that, there's no emphasis on keeping the file formats compatible +
  • I won't actively seek ways to get my changes into the mainstream; I will keep on using my svn repo in a manner that (as a side effect) makes such merges easier, tho. If PCB developers decide to pick them up from svn and merge them in the official repo, it's fine (but I personally will keep using my fork anyway). +
  • Most probably I won't merge anything from the mainstream to my fork - the past few years showed that it's unlikely there would be new features I'd need +
  • plans for new features: +
      +
    • pin shapes (a preliminary version is already implemented +
    • 1206 jumpers without having to add them on the schematics/netlist (mostly done; [intconn] and [nonetlist] are the PCB-side features for this) +
    • merge pcb-gpmi; GPMI would be an optional addon, it'd probably stay a plugin, but there should not be a separate repo +
    +
+ + + + \ No newline at end of file