geda-developers team mailing list archive

[Peter Clifton <peter.clifton@xxxxxxxxxxxxxxxxxxxxxxxxx>]

Hi All,

git HEAD watchers amongst you will notice that I just pushed a revert of
Peter Brett's recent changes migrating parts of gEDA to the config
system.

I have been discussing some issues with Peter privately, and he was
aware of my intention in this regard.


Peter and I have been planning how to handle the breakage in the 1.8
series regarding the net-end-cue drawing farce, summarised as:

Prior to 1.8 release:

  * Introduce code to hide net-ends for "named" connected nets
      - Hits JPD and others, including myself.
      - Feature introduces badly coded complexity in libgeda.
      - Feature is NOT well liked, and IMO should be reverted clean.

  * Peter B replaces the above behaviour by drawing arrows suggesting 
    off-page connectivity on nets which are named. This means users 
    can still see something on those net ends.
      
      - This change is almost universally hated, and introduces far 
        more "magic" in gEDA than we want.

**** SADLY, 1.8.0 is released with this behaviour.

After 1.8.0 release:

  * JPD and myself convincingly argue for a revert of the net-end  
    drawing behaviour back to behaviour last released in 1.7.2.
       - IE.. NO DAMNED MAGIC!
       - Users who want to avoid the cue on an unconnected net-end
         can do so with an explicit symbol.

  * Peter B makes a fairly complete revert of the disputed features in 
    git HEAD. This behaviour goes on to be released in 1.9.0.

  * I really want to break our stable branch rules and kill the feature 
    off in the 1.8 series too, as I consider the change in graphical 
    behaviour on existing schematics to be a __SEVERE REGRESSION__.

    However.. breaking our stable-release policy with a huge 
    feature-revert doesn't exactly set a good example for other 
    developers in the project to follow.

  * Peter B suggested to me that I ought to release 1.10.0, based after 
    the 1.9.0 release, but prior to the (not yet complete) configuration
    changes he was making.


So.. I look at this, and realise the number of fixes introduced after
the configuration API migration work. There is no obvious point to
branch a stable-1.10 series from, and any choice would involve either
cherry-picking lots of fixes from git HEAD, or branching later - and
reverting the config API changes in the stable branch.

I have chosen the nuclear option, which is to revert the majority of the
incomplete config API migration on git HEAD. This IMO, makes git HEAD
the potential base for a stable release. (Once a few outstanding
rendering bugs caused by the libgedacairo transition are fixed).


I will in due course, push a feature-branch with the configuration
changes re-instated, where they can live until such time they are
complete.

(I have such a branch ready to push, but wish to discuss with Peter B
some subtleties first regarding the rebase origin point for the series).



My major goals are:

* Stop users using the stable-1.8 series of gEDA ASAP. It is broken, and
we don't do ourselves any favours by letting it stagnate as the de-facto
gEDA version people make new schematics with. (The magic net-end cue
behaviour it shipped _IS_ going away for good with the next stable
release).

* Get git HEAD into a more consistent state for development and release
work. The config API rework is going to be really awesome when it is
complete, but in order to make a stable release, we should have a config
migration path. Peter B doesn't currently have time to work on this, and
I don't want development and releases to get blocked on it.



Finally, I won't release 1.10 just yet, as there are a couple of config
changes which are necessarily present in git HEAD relating to the cairo
renderer and printing changes. I need to figure out a migration plan
before we make a release. (Even if it is just an active decision to
ignore the old config options without a conversion path).

There are some other items on my TODO list, including:

  * Reviewing Peter B's revert of the net-cue "feature". There may have 
    been a couple of desirable bug-fixes / code-cleanups reverted in the
    mix.

  * New renderer doesn't select colour maps correctly for image export
(see lp-1086530)

  * Review config migration implications for Peter B's keymap API 
    changes in commit ef8cf3e9cd75779d17927c5a4ce51104d42a0ada

  * Adding configurability (or a "tick this box never to bug me again") 
    to the (IMO mis-)feature added in commit b78493810a648d775d1681d92f98f80e40a9359d
    (I'm very tempted to remove it for 1.10 series, as it bugs me enough)

  * We should add a "going away date" to the deprecation warnings added to print.scm
    and image.scm in commit 626a2051e6c4b83a6a23237e68aa2ced7bcaac04




I know I'm bordering on unreasonable here, but can I request that all
git HEAD changes until the 1.10 release are held for review. (Please
email this developer list if you want to commit anything).

I'm going to drag gEDA back into working order, but given the amount of
time I have available to do it, I need to get some control back over the
commit process. (Our git tree is a real mess at the moment).


Kind regards,

-- 
Peter Clifton <peter.clifton@xxxxxxxxxxxxxxxxxxxxxxxxx>

Clifton Electronics