kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

We definitely should plan this out carefully to avoid a bunch merge
conflicts.  Please consider carefully making large change sets to
prevent big merge conflicts.  Jon's connectivity changes have been done
for quite some time and I want to get them merged as soon as branch 5.1.
 Obviously this only affects the schematic editor so if anyone has any
large change sets for any of the other editors ready to go, now would be
a good time to let everyone know so we don't step on each other toes.

The one thing that might cross all editors is object inspection.  Tom or
Orson should be able to provide some insight as to what impact this
merge will have.

On 2/9/19 10:17 AM, Jon Evans wrote:
> Figuring this out is a good idea.  Thanks for suggesting it, John!
> 
> My branch contains upgrades to the connectivity and netlisting system in
> eeschema.
> I have been resolving conflicts from time to time as I am able.
> It may be a good idea to get it merged before too much work goes into
> eeschema modern tool framework, since my code changes the behavior of
> some tools.
> On the other hand, most of my code is "under the hood" so I don't really
> mind refactoring my stuff before merge in order to match whatever is the
> status quo.
> 
> https://github.com/craftyjon/kicad/tree/bus_upgrades
> 
> -Jon
> 
> On Sat, Feb 9, 2019 at 6:45 AM John Beard <john.j.beard@xxxxxxxxx
> <mailto:john.j.beard@xxxxxxxxx>> wrote:
> 
>     Hi,
> 
>     I have a few questions about the plan of action for the start of the
>     v6 development window. I feel that since the 5.1.0 bug list[1] is
>     dwindling, there are probably a few people around who are just waiting
>     for a green light on v6.
> 
>     So that they can organise any pending patches better, I'd like to ask
>     about the plan for v6 development opening. As far as I am aware, we
>     will need to juggle the following tasks:
> 
>     1) Removal of legacy canvases and supporting code

I'm assuming you are talking about the board and footprint editors.
AFAIK, no one has any major footprint editor changes queued up so this
would probably be a safe place to start.  Once we determine the extent
of the queued board editor merges, we can coordinate the removal of the
board editor legacy canvas code.

>     2) Further surgery on eeschema w.r.t. modern tool framework

After we merge Jon's connectivity code, the new tool framework coding
can start.  I don't see this effecting any of the new symbol or
schematic file format work that I'm planning on doing.  We should only
focus on implementing replacements for the existing framework initially.
 Once that is implemented and reasonably bug free, then we should start
working on on the fancy new features like object selection, snapping, etc.

>     3) New symbol format work (hopefully relatively self-contained in the
>     plugin architecture)

This should be pretty much self contained.  The goal will be to get the
existing file format functionality stable before we open the flood gates
for new features like pin/gate swapping, pin functions, etc.

>     4) Merging of various completed features from people who have them
>     stored up since before v5 release

If you have big change sets, please let everyone know so we can
coordinate this.  I'm sure I'm not fully aware of everything that is
queued up.

>     5) Normal ongoing bug fixing and development in the background

Let's make sure we remember to cherry-pick bug fixes to the 5.1 branch.
 I know this can be a pain as the development branch diverges from 5.1.
 I suspect v6 development is going to take a while given the
significance of the changes so we need to be diligent about regular 5.1
bug fix releases.

Cheers,

Wayne

> 
>     There order this happens in will be quite important - if the legacy
>     removal/eeschema tooling happens first, the features might not merge
>     cleanly, but at the same time, legacy brings its own ongoing technical
>     debt. If we can set the order down before the v6 floodgates open, at
>     least we can approach the incoming patches in a systematic way.
>     Specifically, if a major legacy-based refactor is anticipated soon
>     after v6 opens, people should expect major rebasing to be required for
>     incoming features.
> 
>     I don't really have any personal preference, as I don't have patches
>     that are both urgent and impractical to rebase if needed.
> 
>     Perhaps a cursory survey of the work people expect to merge after v6
>     might be in order? Links to git branches, etc?
> 
>     Cheers,
> 
>     John
> 
>     [1]: https://launchpad.net/kicad/+milestone/5.1.0
> 
>     _______________________________________________
>     Mailing list: https://launchpad.net/~kicad-developers
>     Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     Unsubscribe : https://launchpad.net/~kicad-developers
>     More help   : https://help.launchpad.net/ListHelp
> 
> 
> _______________________________________________
> 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
>