kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

Vladimir,

The 3 lead developers have been in conference via personal email for the last two days
regarding your recent PCBNEW work.  After some deliberation and consensus detection and
determination, we have decided to
suspend your commit privileges.  This is likely only a temporary condition depending on
what you do next.


Below are our concerns, and the things which if addressed, would convince us to re-instate
your commit privileges:


1) Regarding the use of "class wrappers for integers", you never completed the argument to
a point of having built a consensus.  Both Jean-Pierre, Lorenzo, and myself expressed
disagreement towards this plan in the following thread:

  http://www.mail-archive.com/kicad-developers@xxxxxxxxxxxxxxxxxxx/msg01879.html

Independent of how good or bad the idea is or was, we now have a political problem, and
that is that we currently think you have some "team player" issues to improve on.  Perhaps
an apology and a continuation of the original conversation is needed.



2) Your code is not conforming to the coding standards, even after being requested in
private email by Wayne this week to improve on this.  As of today we can look at the
function UnitDescription() in file common/common.cpp and notice several violations in just
a few lines of code:

a) Star * to be after LENGTH_UNIT_DESC not before UnitDescription()
b) { bracket to be on its own line after first line of function.
c) switch() needs whitespace around the aUnit on both ends.
d) { brack to be on its own line in switch.
e) switch indenting of cases is wrong, cases to be at same level as switch()
f) single line comments are to be C++ not C style..

This you committed in rev 3222, and is an example of what we are saying.



3) Even if you had won the argument in the email thread back on June 23rd, (which you
still must do before potentially wasting
your time on this (3) ), you are not going about the conversion in a way which we would
expect:

a) Your plan is not documented for all to understand.  Your new macros and functions in
common.h are all largely undocumented.
One would expect to see function comments on functions like LengthFromTextCtrl() and all
the new transition macros.

b) The effects of KICAD_NANOMETRE on file formats have not been documented.

c) The anticipated effects of *not* defining KICAD_NANOMETRE in a build, have not been
documented.  Even if this is not defined in a build, I see saved board files now have
floating point dimensions in them which have trailing zeros.  (Suggest %.6g instead of %f to
printf() style functions.)  We normally don't want to inject unnecessary changes in a
board file unless someone pulls the trigger, by defining the pivot #define, which we guess
to be KICAD_NANOMETRE.

d) The blueprint could also be used to describe what you are up to.


In summary, we recognize that it is cumbersome for you to enter into a long debate when
you are
not working in your native language, and the ideas and expressions do not flow as easily.  We
recognize that.  You however, need to recognize that the lead developers do not have time to
express disagreement more than once.  A disagreement is a state of circumstance and
current understanding of pros and cons.  It is not necessarily a permanent situation.
Pros can be sold through persuasion, and their weight's can be enhanced.  Cons can also
be.  Disagreements can be permanent or temporary, but it is important to recognize which
state you are in currently.  Moving forward against the wishes of a lead developers in a
state of disagreement, without having built a consensus, is not politically wise, and is
specifically disrespectful.


The advantage you have now is that you can use your code as an example to argue
why we should accept your design.  Your original argument (see link below) was
weak no doubt in part due to the fact that English is not your native language.


  http://www.mail-archive.com/kicad-developers@xxxxxxxxxxxxxxxxxxx/msg01879.html


Perhaps you can point to your current commits via an email, and explain what you think the
benefits are to all the complexity, slower compile times, and reduced human readability.

There is still a possibility that we revert (remove) your changes, but equally likely,
with some
political effort on your part, that we can be persuaded that your changes and
contributions are the correct way to go.  And of course you understand that no one objects
to the idea of higher resolution on the internal units, just the implementation details
are on the table.

We thank you in advance for your conscientious understanding of our concerns, and for your
interest in KiCad.

Dick