kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 10/11/2010 11:24 AM, Dick Hollenbeck wrote:
> On 10/11/2010 09:51 AM, Brian F. G. Bidulock wrote:
>> Dick,
>>
>> On Mon, 11 Oct 2010, Dick Hollenbeck wrote:
>>
>>   
>>> On 10/11/2010 03:30 AM, Brian F. G. Bidulock wrote:
>>>     
>>>> I've done a bunch of work converting PCBNEW's internal unit to
>>>> nanometers.
>>>>
>>>> --brian
>>>>   
>>>>       
>>> You mean in your fork?   Why do we care?
>>>
>>> I mowed my lawn this weekend.
>>>
>>>     
>> It' supposed to be a branch: but you can force it to
>> be a fork if you want to.
>>
>> --brian
>>   
> 
> Look, I just want to re-iterate the concerns I brought up about this 6
> months ago. 
> 
> I did not think it was a good idea then, and I still feel that way.  In
> general, we welcome your contributions.  You bring a great deal of
> expertise to the project. 
> 
> But when your contributions start to feel like a body blow inflicted
> with a whole slab of beef, rather than bite sized incremental
> improvements that we can digest and understand in a few minutes, some
> folks begin to question this.  And I am not speaking only about me.

I can speak from experience that trying to make big changes to existing Kicad
source is extremely difficult without breaking something due to the shear
amount of code.  Even though I have commit access and could commit large
changes anytime I wish, I approach large changes incrementally.  This is
primarily to keep the testing branch as usable as possible but it also gives
others a chance to see what I am doing and helps to minimize merge conflicts.

> 
> At some point it becomes an imposition, and overly presumptuous that we
> have to eat the whole slab of beef without time to even look at it, or
> cut it into smaller pieces.

I'm going to use Fabio's EESchema selection patch as an example ( I'm not
picking you Fabio as you have done an excellent piece of work here it is just
that it is an example of what Dick is talking about ).  It is a large change
set that changes a lot of files and which makes it difficult to see where he is
headed.  It also makes changes to gr_basic.cpp(.h) which has the potential to
break every Kicad application.  If you applied this patch, Kicad would not
build on wxWidgets 2.8.x because he used wxPenStyle which does not exist in the
2.8 series of wxWidgets.  He also replaced the current EESchema block select
code without providing any way to compile it out in case it doesn't work or
breaks any other EESchema functionality that he may not have accounted for.  If
you read the PDF ( which is very well done by the way ) file he included, he
even documented that there are issues with the drag function which may make
patch unacceptable to those of us who use testing as our working version of
Kicad.  So what should have Fabio done differently?  He should have announced
his intentions on the dev list and waited for feed back.  His first patch
should have been the low level code in gr_basic and the various schematic
objects with a commit message style explanation of the changes in the merge
request.  Once that patch was applied, other developers could have updated
their working trees to make sure it builds correctly on all of the platforms
folks are using.   In the mean time could be working on the next change set.
Then he could submit the patch that connects the new block selection code at
the UI level that could be easily be compiled out in case something is broken.
 Once the new block selection code was validated an generally agreed upon as
the way go, the conditional compilation could be removed.  Now Fabio is free to
repeat this process for his block drag improvement that he would like to make.
 At this point he may have also impressed the primary developers sufficiently
to grant him commit access which would have made the primary developers happy
that there is another body to help out that can work within the project structure.

> 
> Its time to focus on what it will take to be a team player.  Being
> right, bringing excellent beef, may not be the only thing important at
> this point.

And to this end, this is not an attempt by the primary developers to show
absolute control over the project.  It is merely a way to maintain sanity in
the Kicad development process.  I think everyone on this list can understand
the perils of have a wild west development model where anyone can commit
anything at anytime.  I'm generally a pretty agreeable person ( at least in my
mind ;) ), but that is a project structure that I could say no to with absolute
certainty.

Wayne

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