Mail Archives: geda-user/2013/06/08/08:16:03
This is a repost with reduced number of spelling errors:
Markus Hitter wrote:
> People no longer care about non-
> blocking bugs, don't look at patches and those doing development
> usually keep the result in their own locker out of an totally
> unfounded fear to mess something up or, worse, don't even get the
> idea their work would be welcome.
Well, geda is not exactly known to happily accept contributions by
people from outside an inner circle of core developers. Patches tend
to not be applied, even if they were reported to fix the respective
problem. Many bug reports, even ones with patches, stay without any
response whatsoever.
New features get relegated to be "plug-ins" rather than be integrated
into the main application. That way, they tend to break silently
when the main branch moves ahead. The plug-ins are not delivered as
part of geda. They have to be downloaded and compiled individually
by the user for every version of the application. This drastically
decreases the already small user base. In addition, there is a
strong psychological signal saying: "This is a closed shop. Please
don't expect us to accept your contributions"
> I see this especially with
> projects trying to do high quality work, not so much with chaotic
> development models used by Linux & Co.
I am not convinced that open source development is generally more
chaotic than closed source. Just because you don't see less than
optimal structures from the outside does not mean, everything is
fine behind the veil of a binary blob. There are plausible reasons
that even the opposite may be true. The very fact, that every code
path is explicitly visible to the public provides a motivation for
excellence.
> That general note said, please simply commit this renumber command.
> We have source code management, so things can't get worse. I say so
> without even investigating what would be wrong with the current
> renumber capabilities.
My most pressing wish with regard to renumber scripts:
Play nice with multi part symbols.
It is good practice to split power pins or function blocks of
integrated components into separate symbols. Thy all share the same
value of the refdes attribute. This sameness of refdes values lets
gedalib know that two symbols are meant to refer to the same
component. The same applies to slotted symbols.
The current renumber script in gschem ignores this. It assumes, that
no refdes shall ever be duplicated and allocates individual refdeses
no matter what. Since I use symbols with split power pins in almost
every schematic, this makes automatic renumber a lot less useful
than it could be.
A simple low level way to improve the situation would be an option
to just keep duplicate refdeses duplicate. E.g, two components with
refdes=U5 would both end up with refdes U=13. Of course, this
simplistic approach also leaves accidental duplicates intact. It
still would be a major improvement for my kind of projects.
Some more elaborate logic might come handy to properly differentiate
between deliberate and accidental duplicates. The symbol already
"knows" about the number of slots. So the renumber script can check
weather or not duplicates are consistent with slotting. This concept
can be extended to split symbols:
Add attributes to the symbol that give hints on possible associated
symbols. The symbol opamp.sym might contain an attribute that points
to a symbol with the proper power pins. Like this:
associated=opamp_pwr
Similarly, the symbol opamp_pwr.sym would contain an attribute:
associated=opamp
In an ideal world, there would also be clues whether or not an
associated symbol is optional or should be enforced. Anyway, even
the very simple option to not touch duplicates at all would improve
my renumber experience a lot.
---<)kaimartin(>---
--
Kai-Martin Knaak
- Raw text -