I’m fine with it either way (my stuff is currently equivalent between the two).
> On 19 Jul 2018, at 16:28, Maciej Sumiński <maciej.sumin...@cern.ch> wrote: > > It will be a huge motivation for us to fix GTK3 problems as soon as > possible. I assume you mean to drop the current master branch (or rename > to 6.0?) and make 5.1 the new master branch? > > On 07/19/2018 05:19 PM, Wayne Stambaugh wrote: >> You are preaching to the choir. I did most of the maintenance on the >> 4.0 branch. Initially it was easy but it didn't take long for it to >> become a PITA. If no one else objects, I would be more than happy to >> make that the policy. If that is indeed what we want to do, I would >> delete the 5.1 branch. It will push v6 development back significantly. >> >> On 7/19/2018 11:10 AM, Jon Evans wrote: >>> FWIW, as someone who is also maintaining parallel feature branches, I >>> agree with Orson and John. Now that we have committed to this 5.1 idea, >>> we should just make it happen in master. I think if we keep both master >>> and 5.1 branch running in parallel, inevitably one or the other of them >>> will be less tested / more broken unless people spend a bunch of time >>> doing the work of keeping them synchronized manually. The cost of this >>> doesn't seem to outweigh the benefit of being able to merge some 6.0 >>> features into master sooner. >>> >>> On Thu, Jul 19, 2018 at 11:03 AM John Beard <john.j.be...@gmail.com >>> <mailto:john.j.be...@gmail.com>> wrote: >>> >>> On Thu, Jul 19, 2018 at 1:47 PM, Wayne Stambaugh >>> <stambau...@gmail.com <mailto:stambau...@gmail.com>> wrote: >>>> Unless we are going to prohibit new features (new file formats, >>> new tool >>>> framework for eeschema, etc.) from being merged into the dev branch >>>> until 5.1 is released, I disagree. If we want to only work on 5.1 in >>>> the dev branch, then I'm OK with this proposal. >>> >>> This is essentially my proposal - limit dev branch changes to 5.1 >>> features, uncontroversial maintenance and bugfixes. >>> >>> If people want to work on features for 6 now, that can be done in >>> separate branches, and the onus for keeping it rebased onto the 5.1 >>> changes is on them, rather than forcing the 5.1 workers to deal with >>> conflicts. Otherwise, whoever is working on 5.1 features like the >>> GTK3/GAL stuff and printing, will have to continually port their work >>> between the two branches. >>> >>> If 5.1 changes are unlikely to be substantially affected by 6.0-facing >>> changes, then perhaps this limitation is not useful. >>> >>>> There should be nothing in the 5.1 branch that is not also in the dev >>>> branch so everything in the 5.1 branch should be tested in the dev >>>> branch builds. >>> >>> In theory, yes, but if fixes need to be manually ported as the >>> branches diverge, it's possible to fail to fix, or break in new ways, >>> one branch or the other. If a 5.1 branch exists in parallel to 6.0, >>> someone will have to take responsibility to ensure the appropriate >>> fixes are identified, ported and tested as needed. In the Linux world, >>> this is the unglamorous, arduous (and vital) job of the stable branch >>> maintainers. >>> >>> I'm not against parallel branches if someone is willing to step up to >>> be a stable branch maintainer for 5.1. In fact, I'd be thrilled to get >>> nice new stuff dropping into the dev branch. However, changes that >>> need to be in both branches are not trivially rebasable, that job will >>> soon become decidedly not-fun. >>> >>> Cheers, >>> >>> John >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~kicad-developers >>> <https://launchpad.net/%7Ekicad-developers> >>> Post to : kicad-developers@lists.launchpad.net >>> <mailto:kicad-developers@lists.launchpad.net> >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> <https://launchpad.net/%7Ekicad-developers> >>> More help : https://help.launchpad.net/ListHelp >>> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp