kicad-developers team mailing list archive

[Jeff Young <jeff@xxxxxxxxx>]

+1

> On 19 Jul 2018, at 16:57, Seth Hillbrand <seth@xxxxxxxxxxxxx> wrote:
> 
> 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 <stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>:
> 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.beard@xxxxxxxxx <mailto:john.j.beard@xxxxxxxxx>
> > <mailto:john.j.beard@xxxxxxxxx <mailto:john.j.beard@xxxxxxxxx>>> wrote:
> > 
> >     On Thu, Jul 19, 2018 at 1:47 PM, Wayne Stambaugh
> >     <stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx> <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>> 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/~kicad-developers>
> >     <https://launchpad.net/%7Ekicad-developers <https://launchpad.net/%7Ekicad-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>
> >     <https://launchpad.net/%7Ekicad-developers <https://launchpad.net/%7Ekicad-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>
> 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     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp