kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 07/09/2010 06:53 PM, Brian F. G. Bidulock wrote:
> Dick,
>
> On Fri, 09 Jul 2010, Dick Hollenbeck wrote:
>
>   
>> That is a lot of stuff. 
>>     
> Unfortunately there is more... a lot more.
>
>   
>> Just curious, were you initially undecided about sharing your work?   
>> Why wait so long?
>>     
> No, I always intended on submitting my work back into
> the project.
>
> Being a maintainer of a >1 million line code-base, I far
> prefer the approach of baby steps: a long sequence of
> small changes checked in at each point.
>
> However, there are times where things cannot be achieved
> by organic growth alone.  Although pcbnew looks nice on
> the outside, the inside lacked proper design patterns and
> MCV separation.
>
>   
>> We look forward to seeing it.
>>     
> I also would have preferred to vet design changes through
> the development team, but unfortunately we could have
> discussed things for years without getting anywhere.
>
>   
>> Just an observation:  the more un-merged code you create, the larger the
>> task of getting it back into the project.
>>     
> I am keenly aware of that.  The great majority of changes
> have been to pcbnew (and unfortunately every change to pcbnew
> seems to required a another set of changes to drag gerbview
> screaming and crawling along with it).
>
> I have been merging (well, "update"ing) all changes to the
> testing branch as I am going along.
>
> Unfortunately, within pcbnew, the changes are widespread
> and extensive.  I am sitting at:
>
>     353 files changed,
>     60814 insertions,
>     2030 deletions,
>     27157 modifications.
>
> Yah, I know, that sounds like a lot.  Filtering out fpb and
> dialog code (which is generated automatically), is is more
> like:
>
>     281 files changed,
>     31327 insertions,
>     1687 deletions,
>     18508 modifications.
>
> Don't worry about the little things.  I'm am smart enough
> to hold to coding convention.
>
>   
>> Maybe you don't need to be told this, and have the optimal solution in
>> mind already.
>>     
> You don't have to accept these changes and certainly not until
> they can be reviewed and test driven.  I am certainly not trying
> to tell you how to maintain the project: I know it is a daunting
> task.
>
> I would, however, suggest using the submission to form a separate
> launchpad branch from "testing", incorporating these changes
> for review and test-driving before even contemplating a merge.
> You and the other developers will want to determine whether the
> benefits outweigh the effort.  There are several things that I
> cannot do: translations for gui additions being one of them,
> testing on windows and mac being another.  I can offer to keep
> rolling updates and fixes from "testing" into the newer branch.
> I am a good tech writer too and can update documentation in
> English.  Then at some point you must of course decide whether
> to switch to the newer branch or abandon it.
>
> How does that sound?
>   


Like Christmas, sponsored by a Santa Claus we have yet to meet.

Can't wait to start unwrapping.   :)

I'm sure there will be mostly good with some bad, life is like that.

Thanks,

Dick