kicad-developers team mailing list archive

[Jeff Young <jeff@xxxxxxxxx>]

Oh, and we should merge the airline-route (curved) ratsnest stuff early too, since the author has been waiting a long time.

Cheers,
Jeff.


> On 9 Feb 2019, at 20:35, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
> 
> 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>
>>> <mailto: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 <https://launchpad.net/~kicad-developers>
>>>>    Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>>>>    <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>>>>    Unsubscribe : https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
>>>>    More help   : https://help.launchpad.net/ListHelp <https://help.launchpad.net/ListHelp>
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>>>> Unsubscribe : https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
>>>> More help   : https://help.launchpad.net/ListHelp <https://help.launchpad.net/ListHelp>
>>>> 
>>> 
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>>> Unsubscribe : https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
>>> More help   : https://help.launchpad.net/ListHelp <https://help.launchpad.net/ListHelp>