Second thread
In the second thread I will focus on actual contribution. For this,
I'm narrowing down what exactly needs to be contributed:
- 1. minor UI changes, most probably in the C part of the gschem code.
somehow ending up in the official repo; I'd prefer to avoid maintaining a
fork of gschem (no, having the fork in git doesn't help).
- 2. a scheme script that can be plugged into gschem and do real simple
things like toggling flags for point 1, counting how many flags are
toggled, warn the user about the counter is being non-zero; this script
doesn't need to get into the official repo
- 3. depending on whether we (me and my actual contributor who contributes
code) go for push or pull, we need: a new action or menu or whatever that
can trigger a pull or some means that can collect a change list pushed and
then indicate that something's happened. It's not really a third piece of
code, just a third piece of concept that is spread across 1 and 2.
First, I seek a contributor for exactly these 3 things. Alternatively if
there's someone who is really willing to contribute actual code and spend
time on this, I'm open to change parts of my plan if he has better ideas
as long as the new approach still solves the actual problems I have.
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.