X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Message-ID: <55E92827.7060307@xs4all.nl>
Date: Fri, 04 Sep 2015 07:12:07 +0200
From: "Bert Timmerman (bert DOT timmerman AT xs4all DOT nl) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.19) Gecko/20110429 Fedora/2.0.14-1.fc13 SeaMonkey/2.0.14
MIME-Version: 1.0
To: geda-user AT delorie DOT com
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> <201509032330 DOT t83NU2PZ022982 AT envy DOT delorie DOT com>
In-Reply-To: <201509032330.t83NU2PZ022982@envy.delorie.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: geda-user AT delorie DOT com

DJ Delorie wrote:
>>> 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.
>
>    
Hi all,

I think a new sibling in the geda-family of tools can have a unique 
first name "xorn".

No reason to rename to the existing sibling "gnetlist".

Also for "orange", no need to change that one too.

Just my 2 cents on the matter.

Kind regards,

Bert Timmerman.

BTW: "xorn" will save us a few key strokes ;-)