← Back to team overview

kicad-developers team mailing list archive

Re: Concerns about clearing disagreements before committing.

 

Well thank you ! just to make the end users life a misery ? Hopefully you can at least keep them compatible if you must split and make sure versions remain compatible. KiCAD is a nice program although it needs work doing to it. Please don't ruin the only option we do have in the hobbyist world for a serious PCB suit.

View of an end user !

On 22/11/2011 13:05, Brian F. G. Bidulock wrote:
Vladimir,

I think that the time has come to fork kicad.  It cannot evolve
under its current masters.

Looking at the code, the first thing that I did was change all
members to private and used the compiler to force the use of
proper accessor member functions throughout.  This is necessary
to do the least little thing with pcbnew.  But it appears that
the current "masters" do not like to program in C++: they make
all members public and access them directly from everywhere.
When you try to correct it, they complain that it might break
something, when to an experienced C++ programmer it is seen as
broken by design.  Hummph.  Even to a C programmer is poorly
written.

Then they make "coding standards" that specify which whitespace
to put around their bad code.

These things, coupled with an accute resistance to any change
that isn't a bug fix, makes it impossible for any experienced
C++ programmer to contribute more than one liners to this
project.  I experienced pretty much the same response as you
did (but I didn't push as hard or even get commit access).
Others have gone their own way in the past.  It is a pity
because it always seems to be pcbnew that is the breaking
point for most.  As it stands pcbnew lacks features that were
in other free tools 20 years ago.

Here is a short list of things that cannot be done without
tearing out all the bad code in pcbnew:

- change the internal unit
- remove the limit on number of copper layers
- add technical layers
- properly support buried and blind vias
- apply DFX rules
- avoid round-off errors
- change the internal autorouter (this one is strange as
   kicad was reportedly originally intended for autorouter
   experimentation).

The list goes on.  But, of course, the current "masters" will
tell you that none of these things really needs to be changed,
because they do not constitute a bug fix.

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

Follow ups

References