← Back to team overview

kicad-developers team mailing list archive

Re: Concerns about clearing disagreements before committing.



Thanks for your response.

> At least we all have to be clear in what we say. 

I agree.  The discussion in June sort of tailed off, and it seems we left it with
different understandings.

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

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.

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

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

>> 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. 
> I thought I wrote enough above to express my concepts. If it still did not 
> understood, I apologize again.
>> Your new macros and
>> functions in common.h are all largely undocumented.
> Did you mean 'largely uncommented' under 'largely undocumented'? I hought the 
> purpose and meaning would be clear after looking on their name and source code 
> (especially if there are just a few lines of it).
>> 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.
> I can express the effect in one sentence "Length-dimensioned data is stored 
> with integer and fractional parts separated by 'full stop' (.) character 
> rather than just integer". Would it be enough for documentation?
>> 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.)
> What are your arguments?
> My ones are: For "%f", atoi() still able to decode it, just dropping 
> fractional part, and the absoulte precision of "%f" is constant.
>>  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.
> It shall not effect on *saving* untill KICAD_NANOMETRE is triggered. If it was, 
> it is a bug. But I still can not reproduce it in current revision.

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.

> On loading it should accept old and new files.
> --- that's the comment where it is documented ---
> // there would be some period while program gain ability to
> // load float data but not acually save it
> (rev3241:lengthpcb.h:93-94)
>> 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.
> You could explain you wishes in order they're fullfilled. I still dislike any 
> politic games.
>> 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.
> Try to take some member with length dimension, e. g. TEXTE_MODULE::m_Pos0
> amd try to mak them hold value in nanometers. Count how much time you spent 
> debugging it. Then compare with my results. That's my argument. LENGTH and 
> LIMITED_INT are just a debug helpers, and can be turned to just ints in 
> release or if they're unnecessary to debug.
>> 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.
> What you're mean under 'complexity'?
> Did you compare compile time? If you bother on it you still may compile it 
> with KICAD_NANOMETRE turned off.
> What you're mean under 'human'? I do not see an impact to 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.
> It seem to me the best way for me is to fork/branch (at leash until I have 
> good working concept), 'cause it's too much for me to do work twice writing 
> the same in two languages (English and C++ I meant).
>> We thank you in advance for your conscientious understanding of our
>> concerns, and for your interest in KiCad.
>> Dick
> 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.


Follow ups