kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

Creating separate branches with large change sets is risky.  I've stated
many times before that my time is limited and reviewing a 10K+ lines of
code merge request is likely going to sit in the queue for a long time
until I or someone who's coding ability I trust can find time to review
the changes.  I will not blindly commit anything to the product branch.
 I have repeatedly asked that devs do incremental changes so I can
easily review them.  Incremental changes give me a chance to follow you
thought process on code design and stop you before you code yourself
into a hole.  Is it a PITA?  Yes.  Until I start getting paid full time
to work on KiCad, that is how I plan on doing things.  It can be done.
After the stable release, I will start incrementally committing my
Eeschema base code refactor.  If you follow it, you should be able to
tell where it's headed after the first few commits.  I could do it in
one big merge but I wont.  I know from experience that big changes can
and do leave the code in an unusable state.  One of the goals of the
project is to keep the development branch as bug free as possible.  No
one will want to test the product branch if it's not reasonably stable
and testing is very important.  The other primary goal is code quality.
 The kicad code base is too large to add poorly designed code.

On 11/4/2015 6:47 PM, Mark Roszko wrote:
> Actually right now, officially we are doing current code maintenance
> only as we are trying to do a "stable" release. Its also why things
> have quieted down as people have went to squirrel away on personal
> branches as no new features are accepted right now.
> 
> _______________________________________________
> 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
>