← Back to team overview

kicad-developers team mailing list archive

Re: Concerns about clearing disagreements before committing.


On 11/30/2011 2:29 PM, Dick Hollenbeck wrote:
> On 11/22/2011 08:12 AM, Brian F. G. Bidulock wrote:
>>> Lorenzo,
> :
>>> To do the least little thing, you have to get rid of the legacy
>>> first.  It is obvious from the code.  So, my question, under
>>> the current "managmement", why has this not happenned?  For so
>>> many years.  My only conclusion is that the current "management"
>>> is incapable of doing it for one reason or another.
>>> --brian
>> One of the best ways to get started actually contributing to KiCad is to offer byte sized
>> patches which concentrate on one or two public member fields, and provides accessors for
>> these, making the fields protected or private.  I cannot tell you how many of these kinds
>> of patches that Wayne and I have made.  I did scores of them in 2008.  Wayne has done more
>> than that in the last two years.
>> This procedure, if continued by enough man-hours, would transition KiCad more in the
>> direction of an object oriented design.  We remember that KiCad was originally C code not
>> C++.  So it has been in evolution for the last several years, all the while churning out
>> boards that we all benefit from.
>> Current "management" is incapable of doing this because current management is not paid
>> enough to work on this project full time.  To help with this evolution, the door is open
>> to more volunteers.  The product of the work should be reasonably sized patches,
>> addressing one or two fields at a time.  Even doing this, these are sometimes thousand
>> line patches.
>> No disagreement on the need.  Just in attitude, and willingness to contribute in a way
>> that is appropriate.
>> Dick
> After further consideration, I revise my position, and tend towards Brian's point of
> view.  There is NEW code being written that is not being respectful or our goal towards
> effective C++.

Given all of the object encapsulation and global variable elimination fixes
I've made over the years, I thought I was immune from this one but I found one
of my classes (only DANGLING_END_ITEM so far, there may be others) with public
member variables.  I hang my head in shame. :(  I know better.  I have added it
to my todo list.  I will continue fixing these issues in legacy code as I find

> Specifically new code is adding public members, and not using accessors.  In fact, I would
> say a considerable amount of new code.
> I no longer have any answers to this problem.  We have to get more buy in from others in
> the project, including Jean-Pierre.

You have my continued support.


> Dick
> _______________________________________________
> 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