Index: trunk/doc-rnd/devlog/20150901a_back_ann.html
===================================================================
--- trunk/doc-rnd/devlog/20150901a_back_ann.html (revision 899)
+++ trunk/doc-rnd/devlog/20150901a_back_ann.html (revision 900)
@@ -4,6 +4,7 @@
+ Preparing for the third phase (3rd sep)
+Options are being eliminated slowly. I couldn't find out who are currently the
+maintainers of gschem, so I couldn't ask their opinion about my back annotation
+plan directly. Last stable release is about 2 years old, last unstable is more
+than a year old.
+
+The main options currently are:
+
+ - 1. Evan offered contribution on the gschem side; Markus offered him write
+ access to the official git repo. We could have a branch there. We'd
+ aim for a merge, so minimal changes and a lot of scheme hacking (...
+ that still none of us want to do, afaik).
+ Without positive feedback from maintainers, I believe this branch
+ has a very low chance to get merged in mainline. If it doesn't get
+ merged, all the extra effort on scheme, git, and trying to
+ do things in the gschem-way are just energy wasted.
+
+
- 2. I start an svn repo and implement the stuff the better way (no
+ scheme, bigger change, no worries about whether it gets merged). Keep
+ changes on-topic and small, so later on if someone wants to merge,
+ there's a chance to get it into a branch in the git repo first then
+ do the merge. Has even lower chance to get merged, but certainly
+ speeds up development and is much easier to work on, distribute and
+ use than a bitrotting git branch. If it doesn't get merged,
+ only a small amount of efforts wasted on trying to keep changes
+ merge-friendly.
+
+
- 3. I start an svn repo and implement the stuff the best I can - without
+ considering any merging aspects. This is the option that'd grant
+ the most development speed and efficiency. It doesn't get merged,
+ but no energy is wasted at all and the resulting code is better.
+
+There are some other options, but those are just variants of the above three.
+Currently I think option 1 is unlikely to work, for I don't touch git,
+and noone wants to touch scheme. Both 2 or 3 could work, but the total lack
+of gschem maintainer feedback doesn't make option 2 look too good.
+