kicad-developers team mailing list archive

["Brian F. G. Bidulock" <bidulock@xxxxxxxxxxx>]

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?

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
bidulock@xxxxxxxxxxx    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦