I'd be in favor of this but if we're going to focus exclusively on v5.1 GTK3 migration, can we push the current state, warts and all to the master? We have a bunch of bugs tagged to 5.1 but only one is GTK3-related. I suspect we have a number of things to work on here but without bug assignment, we'll be stepping on each other's toes.
-S Am Do., 19. Juli 2018 um 08:35 Uhr schrieb Wayne Stambaugh < stambau...@gmail.com>: > 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
