[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: Collaborative Development of Boards

John, Stephan, Rick, Tibor,

many thanks for your insights. I'm convinced there _has_ to be some sort of leadership when different, but technological equal design solutions appear.

Am 16.01.2011 um 22:37 schrieb Rick:

To be honest, I was a little turned off when I tried to read your web page and the opening didn't even tell me what you are doing! It referred me to another web site entirely... and then another...

The link I gave is only one of many pages of a fascinating bigger project, so you typically find this page from higher level ones. This bigger project is about building self-replicating machines, and the circuitry shall drive their stepper motors. There are at least a dozen competing circuitries, most of them at a commercial, read-only open source level.

Am 17.01.2011 um 06:28 schrieb gedau@xxxxxxxxxxxxx:

While PCB isn't that bad at keeping changes to the saved file small,
there's always at least the also stored file creation date letting
merges fail.

Yes, I agree on this one. I think storing such modification date is just
the wrong thing to do.

I've filed a bug for this:


As I'm not aware of a use case for this data, I suggest to get rid of it entirely. If somebody has a use case, please speak up there.

The other problem is diff. Again, I don't think there is anessential
difference between team work and VCS in software development and in
using the same methods/tools on other fields; at least we have the same
methods, but some tools are partially missing.

As you mentioned one of the differences is the inspection of changes, but there's another one. Track positions are more like the programmer's object data, than like source code. So they can change often, and often without the intent to change functionality of the layout.

One solution would be to not store track positions at all, but always generate them with an autorouter on the fly. As long as autorouters aren't as full-featured as compilers in the software world, this isn't an option, though. Future music :-)

there's never a version where the changelog says "Deleted 20 unused features. Patched 300 memory leaks. No new features added".

Sure there are. Actually, they're my favourite ;-)

However, your point is totally valid on the other hand: these little
fixes, getting the silk layer look nicer for example, does not make any
sense if you will move half of the elements in the near future, for
example because you don't even have a decision on the connectors yet.

The point isn't about refusing cleanup, it's more about doing such cleanups and all those small changes in seperate commits. Each change in it's own commit, so it can be reviewed or cherry-picked easily. I know, the temptation to do it all in one batch is big, as all the current shortcomings are right in front of your eyes. But you loose a lot later.

Probably a matter of demonstration the advantages ;-)


- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter

geda-user mailing list