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 <[email protected]> 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 <[email protected] >>> <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> 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 <[email protected] >>>> <mailto:[email protected]>> 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 : [email protected] >>>> <mailto:[email protected]> >>>> <mailto:[email protected] >>>> <mailto:[email protected]>> >>>> <mailto:[email protected] >>>> <mailto:[email protected]>> >>>> 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 : [email protected] >>>> <mailto:[email protected]> >>>> <mailto:[email protected] >>>> <mailto:[email protected]>> >>>> 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 : [email protected] >>> <mailto:[email protected]> >>> <mailto:[email protected] >>> <mailto:[email protected]>> >>> 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 Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
