Mail Archives: geda-user/2015/09/04/01:12:20
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 ;-)
- Raw text -