kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

Vladimir,

If one carefully reads your last response, I see that you:

a) Do not find it important to adhere to the coding standards.

b) Do not find it important to give extra weight to the leanings or inclinations of the
lead developers.

c) Do not really want to have a conversation about any of your work, something that a
functioning team must do.


I see that you were added to the team testing-committers when we switched to launchpad,
because Igor added you back when it was thought that anyone who knew how to spell C++
should be added.

What I am finding is that to properly construct a well functioning team, personalities
must be considered.   I find this within my own company and I'm finding it open source
projects.   We have some very good team members on this team.   One of the things I am
most proud about is my contribution to team building within the KiCad project. 

I have been proactive in a number of cases when I identified certain personality traits
that I thought would be good additions to our team.  My response in such cases has been
encouragement and even offering to grant commit rights before the person even asked for them.

Wayne, and Marco Mattilla are two cases in point.  These are both excellent team members. 
Fabricio is an excellent team member.  Many others are also.

My personal feelings are that we would like to keep you as part of the team
"kicad-developers".   However, at this time I do not think it is in the best interest of
the team "testing-committers" to have you as a member.

We need people who are easy to work with, can sell their ideas without feeling like they
are under attack.  In the 5 months that have passed since our original conversation, there
has been considerable movement in my opinion of your original ideas.  It is not impossible
to persuade and sell your ideas.  But it involves compromise, it involves listening, and
understanding the concerns of others so that you can address them.

The only thing I would like to change is that we work together on this.  If that is
something difficult for you, I will understand.  If you would like to work together, that
means we will have to have some conversation, you may send in some proposed patches, and
we may accept them, reject them, or modify them. 

If the process gets any more torturous, then we will simply code this feature
ourselves.    In fact, in private conversation, I have already offered to do that.

Ironically, you still do not even understand

a) what I like about your code, and
b) what my objections are,

The are of persuasion is something we can not avoid it life.  Nothing happens in this
world until somebody sells something.  Sometimes what gets sold is an idea.  The first
thing they tell you in sales is to listen.


Dick



> В сообщении от Суббота 19 ноября 2011 23:43:46 автор Dick Hollenbeck написал:
>
>> The key postings which illustrate my point and my understanding that there
>> was no concensus reached were these:
>>
>> The first one carries the most weight, because it is from Jean-Pierre:
>>
>> 1)
>> http://www.mail-archive.com/kicad-developers@xxxxxxxxxxxxxxxxxxx/msg01887.
>> html
>>
>> And my objections:
>>
>> 2)
>> http://www.mail-archive.com/kicad-developers@xxxxxxxxxxxxxxxxxxx/msg01878.
>> html 3)
>> http://www.mail-archive.com/kicad-developers@xxxxxxxxxxxxxxxxxxx/msg01880.
>> html
> "...I do not see the advantage..."
> "I don't see it..."
> "Its not clear to me..."
> "Java explicitly avoided typedefs..."
> "I hated virtually everything Microsoft introduced..."
>
> Above are not look like an argument but like an personal opinion and/or 
> attitude. It is not an object for a discussion.
>
> You do not see an advantage, but I see. I need for me to track anything 
> related lengths (with the help of a compiler).
>
> Typedef, as any other tool, may help and may hurt. This depends on how you're 
> using it. DWORD and other typedef stuff was developed long before the Windows 
> has come. Mostly they're used where portability is an issue, because 'int' is 
> not so portable thing: name 'int' says only that it is an integer number of 
> range not less than -65535...+65535. But for portability in most cases much 
> more information needed, that's why in C99 (not C++) '[u]int*_t' was appeared 
> (see, they're just a typedefs). It is not the case in ADA where integer limits 
> are set explicitly, but it also have typedef-like syntax, just to define limits 
> only once. In Java AFAIR, typedef is superseeded by inheritance (in c++, int 
> cannot be inherited, only typedef'd).
>
> OTOH if one specific technique made a rule it starts to hurt much, as happened 
> with Microsoft and their typedefs and hungarian notation (it is also not bad 
> then used wisely). Intention of MS's typedefs was to keep system call 
> parameters same machine type while in transition from 16 bit to 32 bit (int 
> and pointer are different when compiled in 16 bit and 32 bit modes!). Long time 
> only 32 bit machines rule the world and many programmers did not imagine that 
> int and long can have other width than 32 bit. But it can and it causes 
> portability issues.
>
> My case is another. The value which LENGTH type carry is not an integer. It is 
> a physical length and it behave like a length, not like an integer. You do NOT 
> need keep in mind that machine stuff stands beyond its name. It is convenient 
> for me as a developer and switch its type just editing single line and see, 
> what's happen. If I suspect there are overflows somewhere, I may switch to 
> int64 or LIMITED_INT (which I introduce) and quickly catch them. If I suspect 
> roundind errors I may switch to long double (or even reload basic operations 
> to track all roundings in log!). When my work is finished I just switch back to 
> simplest and fastest type.
>
> That's why I'm friend with typedefs.
>
> In many cases all this stuff looks like:
>
>     #ifdef NDEBUG // release
>     typedef int X
>     #else
>     class X ..... (all that debug stuff)
>     #endif
>
> Am I so clear now in that I do?
>
>> However I agree with you that we all could have been clearer.
>>
>> In my mind, when Jean-Pierre objects to something, I tend to take that with
>> a fairly heavily weighted factor, so my lasting perception of the
>> conversation was obviously different than yours.
> When in discussion, personality should not be weighting factor, only the sense 
> of arguments. After the discussion authorized person makes the decision.
> If you decide, that I should not do what I do in kicad, i will not do it there 
> (i'll do it somewhere else). If you decide that it is not needed in KiCad or 
> have to be done in another way, i understand.
>
> I do not know your level of knowledge and expirience and you all do not know 
> my, so we all can not decide how strong our arguments should be.
>
>> Putting that behind us now, are you willing to reopen the discussion and
>> answer some questions by others and myself?
>>
>>> It seems I understood
>>> incorrectly what should I do, and what shouldn't.
>>>
>>> В сообщении от Пятница 18 ноября 2011 21:23:21 вы написали:
>>>> 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:
>>> I do not realize what sort of argument you're want from me. Is it known
>>> method for you to encourage the compiler to catch possible bugs?
>>>
>>>> http://www.mail-archive.com/kicad-developers@xxxxxxxxxxxxxxxxxxx/msg0187
>>>> 9. 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.
>>> Seemingly I'm bad 'team player'. I apologize.
>> Thanks for making this effort.  We are in fact a team, and what we need are
>> team players, especially in those positions which have commit rights to
>> the testing-branch.
>>
>>>> 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..
>>> bcde) was my fault, I still did not spent 15 s to reformat 5 lines of
>>> code, but... It seems my eyes cheat me, but I still do not see the
>>> *rules* for a) and f).
>> a) & f) are in the coding standards document, but there is also the tens of
>> thousands of lines of code in the project which already act as examples.
> Can you cite the *rule*, please? Examples are not rules, though.
>
> My 'native' style too different from what KiCAD use but I believe we all should 
> be tolerant to others. I cannot take as an argument that 'makes it difficult to 
> see' (Wayne wrote), because many people (outside KiCAD project) write like me 
> and read such code and have no difficulties.
>
> However I do not intend to break or change the rules.
>
>> I saw this bug in a recent revision pertaining to
>>
>> Clearance 40.000000
>> TrackWidth 40.000000
>> ViaDia 180.000000
>> ViaDrill 100.000000
>> uViaDia 200.000000
>> uViaDrill 50.000000
>>
>> This raised an alarm with me.  I don't like unnecessary trailing zeros, in
>> any case.
> I cannot reproduce it. If it is still not work as expected, I apologize.
>
>>> p. s.
>>> Do you want to know my (and russian KiCAD developers I met today) point
>>> of view on KiCad sources? Do you find easy to read well formatted
>>> spaghetti like code?..
>> Yes to the above, but only if you think this would be helpful to the
>> project, or to our perception of you.
> I do not intend to offend any of developers, but all sad below is what we 
> agree in.
>
> Altough too much effort in whitespaces, linefeeds and letter case, in general 
> kicad source is bad designed, overcomplicated, ineffective, and thus need much 
> rewrite and refactoring.
>
> For example, that's I've found.
>
> * Several definitions of macros abs, max, MAX, min, MIN and similar in different 
> headers, and sometimes sources (already fixed in my last commit), it seems they 
> are not alone.
>
> * Much stuff related to class internals spreaded all around sources, like this 
> one dealing with TEXTE internals found in MODULE method:
>             pt_texte = (TEXTE_MODULE*) PtStruct;
>             pt_texte->m_Pos.y -= m_Pos.y;
>             pt_texte->m_Pos.y  = -pt_texte->m_Pos.y;
>             pt_texte->m_Pos.y += m_Pos.y;
>             NEGATE( pt_texte->m_Pos0.y );
>             pt_texte->m_Mirror = false;
>             NEGATE_AND_NORMALIZE_ANGLE_POS( pt_texte->m_Orient );
>
> * switch() where polymorphism fit much better (similar to above).
>
> * Lots of hardcoded constants throughout the code.
>
> I understand that much of it is not a result of someone's incompetence and a 
> result of long-long 'evolution', but in my opinion it retards KiCAD 
> development too much.
>
> I think it would be best if lead developers take all in their 
> plans, e. g. by creating nice blueprints which we all will take cue from.
>