Re: gEDA-user: Collaborative Development of Boards

[Markus Hitter <mah@xxxxxxxxxxx>]

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:

https://bugs.launchpad.net/pcb/+bug/703914

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 ;-)


Markus

- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.jump-ing.de/







_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user