← Back to team overview

kicad-developers team mailing list archive

Re: Improving usability of KiCad

 

On 10/11/2010 3:27 PM, Brian F. G. Bidulock wrote:
> Dick,
> 
> On Mon, 11 Oct 2010, Dick Hollenbeck wrote:
>>
>> Look, I just want to re-iterate the concerns I brought up about this 6
>> months ago. 
>>
>> I did not think it was a good idea then, and I still feel that way.  In
>> general, we welcome your contributions.  You bring a great deal of
>> expertise to the project. 
>>
>> But when your contributions start to feel like a body blow inflicted
>> with a whole slab of beef, rather than bite sized incremental
>> improvements that we can digest and understand in a few minutes, some
>> folks begin to question this.  And I am not speaking only about me.
>>
>> At some point it becomes an imposition, and overly presumptuous that we
>> have to eat the whole slab of beef without time to even look at it, or
>> cut it into smaller pieces.
>>
>> Its time to focus on what it will take to be a team player.  Being
>> right, bringing excellent beef, may not be the only thing important at
>> this point.
> 
> What are you talking about?  Metric units?
> 
> Metric units is a no-brainer.  Every _other_ PCB CAD system has been
> using them for, oh, about the last 30 years or so.  For some of the
> technical problems that results from a poor selection of internal units,
> see my other notes on this thread.

I agree with your internal units assessment, but this the last argument I would
use to rationalize the change.  I can hear my mom's voice "If everyone else was
jumping off a cliff, would you do it too?" :)

> 
> For more of my thinking on the changes that I have embarked upon,
> see the current copy of my design notes here:
> 
> 	http://www.openss7.org/docs/NOTES.pdf
> 
> Warning: only start reading this if you are interested in several hundred
> pages of ramblings.
> 
> As for putting up a branch, I would, but I don't need a whole PPA thing, I
> don't care to sign any agreement.  If someone can direct me towards some
> quick pointers for setting up a bzr branch somewhere where you all can get
> at it, let me know and I'll see about doing it.

I did not have to sign any PPA to commit code to Launchpad.  I think as long as
you have your developer profile configured properly you should be able to
publish your branch.  See the "Publishing your branch with Launchpad" section of:

http://doc.bazaar.canonical.com/bzr.dev/en/mini-tutorial/index.html

> 
> As to incremental changes, I believe we discussed those before: all
> siginificant progress requires a quantuum leap or rewrite at some point:
> just like the EESCHEMA library code.

What Dick is doing does not disrupt the current code base.  Changing the
internal units has the potential to.  I see no reason why the internal units
change could not have been made incrementally.  It may take a bit more work to
make changes incrementally but I think it is a sound development model.  I
submit the Linux kernel as my example.  Each new branch of the kernel has been
fairly incremental in order to avoid instability.  I see Dick's work like
adding new device driver to the kernel rather than a core kernel code.  If the
device driver doesn't work, we just don't get to use that device.  If EESchema
doesn't work, then we don't get to lay out schematics.

Wayne


> 
> --brian
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 



References