kicad-developers team mailing list archive

[Tomasz Wlostowski <tomasz.wlostowski@xxxxxxx>]

On 29/11/17 14:57, Heikki Pulkkinen wrote:
> Hi Wayne,
> 
> Thanks Wayne for answering me.
> 
> "if you want to be a member of Kicad developers," that is blackmailing.
> 
Hi Heikki,

I had no intention at all to insult or blackmail. In fact, I like very
much the features you showed (especially the stiching code/teardrops)
and I'm looking forward to have them in Kicad.

Tom

> 
> Heikki
> 
> 
> On Wed, Nov 29, 2017 at 3:22 PM, Wayne Stambaugh <stambaughw@xxxxxxxxx
> <mailto:stambaughw@xxxxxxxxx>> wrote:
> 
>     On 11/29/2017 8:08 AM, Heikki Pulkkinen wrote:
>     >
>     > Hi
>     >
>     >
>     > On Wed, Nov 29, 2017 at 1:32 AM, Tomasz Wlostowski
>     > <tomasz.wlostowski@xxxxxxx <mailto:tomasz.wlostowski@xxxxxxx>
>     <mailto:tomasz.wlostowski@xxxxxxx
>     <mailto:tomasz.wlostowski@xxxxxxx>>> wrote:
>     >
>     >     On 28/11/17 18:25, Heikki Pulkkinen wrote:
>     >     >
>     >     > Zones filling new record with new connectivity algo with
>     A64-Olinuxino
>     >     > board. 13s.
>     >
>     >     Heikki,
>     >
>     >     I would be very glad to include your improvements in the zone
>     filling,
>     >     but the code you've sent to me (your Github) does not meet the
>     quality
>     >     standard we expect:
>     >     - It's a mix of object and non-object oriented code which is
>     diffucult
>     >     to understand.
>     >
>     >
>     > Can you specify what part is object and what are not?
>     >
>     >     - It doesn't follow Kicad coding style rules.
>     >
>     >
>     > Maybe, but can you specify that too? I can not see.
>     >
>     >     - It contains much more than faster zone filling, everything
>     is mixed
>     >     with your via stitching/thermal code that we did not accept
>     for the
>     >     reasons we had already explained to you.
>     >
>     >
>     > Yes of course, it is my developed and going to use it in that way.
>     >
>     >
>     >     I also investigated why the zones are filled slowly - the
>     major reason
>     >     was a bug in the GAL zone filling algorithm, which was filling
>     all zones
>     >     by performing N independent fills of every zone causing the
>     isolated
>     >     copper islands to be checked N times (where N=number of zones
>     in the
>     >     design) instead of just once. The branch [1] contains this bug
>     fixed. It
>     >     also introduces quite a speedup in zone loading/rendering and
>     >     parallelizes all zone filling operations using OpenMP. It
>     refills all
>     >     zones on the "A64-Olinuxino
>     >     board" in less than 3 seconds and something around 10s for the
>     "wrs"
>     >     board on a Core i7-4700MQ, 16GB RAM machine.
>     >
>     >
>     >  
>     >
>     >     Please, if you want to be a member of Kicad developers, follow
>     some
>     >     rules:
>     >
>     >
>     > Of course you want that!
>     > Wayne, do you accept this kind of blackmailing and all these rules?
> 
>     I see no blackmailing here.  Tomasz is just pointing out the rules that
>     all KiCad developers are expected to follow when making contributions to
>     the project.  These rules apply to everyone including the project leader
>     so you are not being singled out.  You are being asked to help make life
>     easier for the lead developers so that they can possibly merge your code
>     into KiCad.  If your code does not conform to the coding policy[1], your
>     repo cannot be easily merged into the main kicad repo, or your code is
>     difficult to follow then you cannot expect someone else to fix this for
>     you.  The lead kicad developers are busy and do not have the time to do
>     this.
> 
>     Cheers,
> 
>     Wayne
> 
>     [1]:
>     http://docs.kicad-pcb.org/doxygen/md_Documentation_development_coding-style-policy.html
>     <http://docs.kicad-pcb.org/doxygen/md_Documentation_development_coding-style-policy.html>
> 
>     >
>     >     - Ask before making heavy changes. Connectivity algorithm is
>     an example
>     >     of a heavy change.
>     >
>     >
>     >     - Don't introduce large or risky changes in your first
>     patches. Changing
>     >     the file format is an example of a potentially risky change
>     that should
>     >     be consulted with other developers.
>     >
>     >
>     >     - Announce you're working on something before you start
>     writing the
>     >     code. Someone else may be already working on this part - which
>     is what
>     >     exactly happened with the connectivity algorithm
>     >
>     >
>     >     I'll be very happy to have a look at your teardrops and
>     automatic zone
>     >     stitching code - which IMHO is an very valuable addition to
>     Kicad -
>     >     after the V5 stable release is out.
>     >      
>     >
>     >     Cheers,
>     >     Tom
>     >
>     >     [1]
>     https://github.com/twlostow/kicad-dev/tree/tom-faster-zones
>     <https://github.com/twlostow/kicad-dev/tree/tom-faster-zones>
>     >     <https://github.com/twlostow/kicad-dev/tree/tom-faster-zones
>     <https://github.com/twlostow/kicad-dev/tree/tom-faster-zones>>
>     >
>     >
>     > Why are you yelling all the time that connectivity algo for me?
>     > Why do you think that other people do not have rights to do
>     experiments?
>     > I am going to do my experiments and tests anyway. And I do not want to
>     > use my time for this.
>     >
>     > I thought  this is open source, and all kind of ideas should be
>     accepted
>     > as an idea. Even if they make any "sense".
>     >
>     >
>     > Regards
>     >
>     > Heikki
>     >
> 
> 
> 
> 
> _______________________________________________
> 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
>