kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

This might cause issues with Jon's work so we should let Jon merge his
code first since I'm sure his changes are far more significant and then
you will have to rebase against his changes.  Hopefully it wont be too
painful.

On 2/9/19 1:00 PM, Jeff Young wrote:
> Most of my 6.0 branch changesets are small.  The one that might have
> conflicts is the escape-netnames one (which allows spaces, etc. in
> netnames).
> 
> Cheers,
> Jeff.
> 
> 
>> On 9 Feb 2019, at 17:32, Wayne Stambaugh <stambaughw@xxxxxxxxx
>> <mailto:stambaughw@xxxxxxxxx>> wrote:
>>
>> 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>
>>>    <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
>>> <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
>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>