X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
Date: Thu, 3 Sep 2015 19:30:02 -0400
Message-Id: <201509032330.t83NU2PZ022982@envy.delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: geda-user AT delorie DOT com
In-reply-to: <FA19D3BF-51B4-4345-84D1-F5F9AC0000D7@noqsi.com> (message from
	John Doty on Thu, 3 Sep 2015 16:39:27 -0600)
Subject: Re: [geda-user] New experimental netlist features
References: <alpine DOT DEB DOT 2 DOT 11 DOT 1509031356150 DOT 13201 AT nimbus> <55E8773B DOT 9000902 AT jump-ing DOT de> <alpine DOT DEB DOT 2 DOT 11 DOT 1509031846370 DOT 7163 AT nimbus> <55E8831A DOT 8050307 AT jump-ing DOT de> <alpine DOT DEB DOT 2 DOT 11 DOT 1509032004020 DOT 10628 AT nimbus> <55E891FA DOT 2010509 AT jump-ing DOT de> <alpine DOT DEB DOT 2 DOT 11 DOT 1509032039300 DOT 14871 AT nimbus> <BC7E3E69-4914-4654-B020-1338C71E0CDB AT noqsi DOT com> <201509032030 DOT t83KU1Yq017045 AT envy DOT delorie DOT com> <FA19D3BF-51B4-4345-84D1-F5F9AC0000D7 AT noqsi DOT com>
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


> > Do we want to retain backwards compatibility?  Yes.  Do we want to do
> > so at the expense of new development?  No.  How do we reconcile these
> > two goals?  I don't know, and nobody has offered a workable solution.
> 
> Actually, for netlisting, I think we do. Keep gnetlist and bring in xorn.

Except that leads to the "memorable" name "gnetlist" referring to a
then-obsolete command, and "xorn", which doesn't seem to have a
project-related name, being the new way.

IMHO It's ok for a generic name like "gnetlist" to be reused for
something new that still does basically the same function from the
user's point of view, as long as there's *some* way for people who
need the old way to still get it.  For example, renaming the existing
gnetlist to gnetlist-scheme if/when we move our recommended gnetlist
to be a link to gnetlist-xorn.  It's a minor one-time inconvenience
for people who need the old way, in exchange for a much more
consistent experience for the common user.

(this is my usual stance of "the common case should be easy, other
cases should be possible.")

> > We certainly can't just leave things the way they are.  That's the
> > road to stagnation and doom as other projects innovate right past us.
> 
> I don't see that happening. Where is an EDA toolkit with anything
> approaching our flexibility?

Innovate != flexibility.  If they come up with a better way to serve
their users, they'll get more users and we'll get less.  Flexibility
is *one* advantage, there are a lot of other things which add to the
user experience.  A text editor is highly flexible but nobody uses it
to do layout (tweak, maybe, do, no).

(as an aside, I've watched mechanical cad users on youtube that are
VERY productive on software that took the opposite approach as we did
- just because a solution is good for a few people doesn't mean it's
the best overall solution)

> > We want to encourage, not discourage, development of our tools.
> 
> New tools, better tools, yes. Unnecessary changes to working tools
> out of a misplaced fear of stagnation, no.

The words "Unnecessary" and "misplaced" overstate your bias (you could
have just said 'Changes to ... a fear of' and avoided the emotionally
charged words completely).  It seems that others disagree about
whether change is needed, and if the fear of stagnation is real or
not.  Your "fear of needed change" is not the best solution for the
project.  We aren't intentionally trying to break your scripts, but we
also can't let one user's unusual setup prevent us from improving
everyone else's experience.

If you were the *only* person needing the old way (and I'm not saying
you are), would it be fair to the project to force us to support you
forever?  Of course not.  So, where do we draw the line?  In the open
source world, the line is drawn wherever the developers choose to draw
it.  We are not contractually obliged to support old versions or users
at all, although of course we prefer to do so whenever possible.

So, sometimes developers may decide that change is neccessary, and
that the fear is real.  Sometimes, that means some users will not be
happy.  Telling the developers not to do that is neither constructive
nor helpful.

> > We certainly can't just ignore our existing user base either, though.
> > gEDA is known for its hackability and that unfortunately locks us into
> > APIs that were never intended, but those hacks do some pretty awesome
> > things.
> 
> Unfortunately? Absolutely not! Is AWK a failure because it's widely
> used, but hardly ever used for scanning telephone switch logs? That
> a tool takes off and does things that its designers never intended
> is testimony to excellent design.

That was not at all what I meant.  I meant, there may be internal
functions that were never intended to be official (or even public),
that someone discovered and (ab)used in a workflow.  There must be a
way to let that API change, despite its use, else we'd be unexpectedly
locked into something we don't want.