pcb-rnd devlog

back annotation

by Igor2

Conclusions of the first thread

DJ has another model where back annotation is only a subset of a bigger mechanism.

Many other users commented the thread, but no one else presented a plan that formed a complete system.

While there were some useful feedback about some details, no one explicitly said he'd be contributing the gschem part (... for any of the ideas floating around).

The thread is swamped in a chaotic set of random ideas and opinions - the same way as previous related threads usually did.

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.