+1 > On 24 Jul 2018, at 08:01, Maciej Sumiński <maciej.sumin...@cern.ch> wrote: > > At the moment the master branch contains all commits from 5.1 and a few > more. It might be the right moment to drop 5.1 branch. > > Cheers, > Orson > > On 07/20/2018 11:14 AM, Maciej Sumiński wrote: >> We already have slightly diverged the branches, I think it shows that it >> is hard to maintain two branches with cherry-picking. Details below: >> >> Commits present in master, but not in 5.1: >> commit c585964da98269db2cabf06daafb0b11cae3a4ec >> fix coding style issues. >> >> commit 840ad7f68053d000dc6d46661d05d9d4be074704 >> Add SH_ARC collisions >> >> commit 01c5bdfb8f49a84f2e5fae5c7fc5729a47c8ef0f >> Fix bug with duplicate columns in Edit Symbol Fields. >> >> >> Commits present in 5.1, but not in master: >> commit 42deb68575a5a415b0970be4a89676f1986fa196 >> Eeschema: minor fix in edit label dialog (incorrect unit value ) >> >> On 07/19/2018 07:08 PM, Wayne Stambaugh wrote: >>> This was pretty much how I saw the development working which is why I >>> created a separate 5.1 branch. However, if we are not going to allow >>> new features to be merged into the master branch (6.0-dev) (and it seems >>> that is the consensus) then I propose that we do all of the 5.1 >>> development in the master branch. I would rather not delete the 5.1 >>> branch because the tags and version strings are already in place and >>> reverting all the changes thus far would be painful. Assuming 5.1 and >>> master are currently the same, we can either merge from master to 5.1 as >>> we go or one big merge when we are ready to start creating 5.1 release >>> candidates. I would prefer that we merge as we go which will keep the >>> two branches synced an minimize issues. Is this acceptable to everyone? >>> >>> On 7/19/2018 12:15 PM, Carsten Schoenert wrote: >>>> Hi, >>>> >>>> for me as a person which doesn't do any active source code development >>>> on KiCad it looks like there is some confusion in the wild what will or >>>> should happen in which branch. >>>> >>>> Sorry if I haven't get it until now, what are the goals of the branch >>>> 5.1 the project wanted to archive? >>>> >>>> And what is 6.0, master or $(what else) are for? >>>> >>>> If these questions can be answered it will be much more clear what >>>> development should happen in which branch and what should be merged into >>>> which other branch. >>>> >>>> KiCad has now more active developers than ever I think, but I can't >>>> really see a branch model that is fitting the current and future >>>> situations. Out there are various branching models and the KiCad project >>>> needs to decide which will work best for the project. The classical >>>> master plus release branches isn't working great anymore if you want to >>>> work on multiple parts in parallel. >>>> >>>> I suggest to have a look at the following website. >>>> >>>> https://nvie.com/posts/a-successful-git-branching-model/ >>>> >>>> It describes what options are count and how a workflow would look like, >>>> I think it would be also usable for KiCad (not in a full blown version). >>>> >>>> In the long term you wont do cherry-picking for the plain development as >>>> this wont work smoothly at one point anymore (as Wayne already >>>> mentioned). Single cherry-picking is fine, but in the end you will come >>>> to merge commits as you mostly want to have all the new code in a later >>>> release. Every upstream project I know is working this way. >>>> >>>> Backporting security or hot fixes are slightly different and require >>>> often cherry-picking with small or much modifications as you wont >>>> introduce new features into old code by merges. But also this can be >>>> done in a local feature branch which gets merged then into the stable >>>> release branch. Depends mostly on the amount of the needed backport. >>>> >>>> So to call it again, what is the branch 5.1 intended for? Only for the >>>> GTK+3 fixes? If yes it's fine to do it here and merged these changes >>>> (which will be needed also in the current ongoing nightly development) >>>> into master, develop, 6.0 or what ever named branch. Just renaming >>>> master into something different without a common and required workflow >>>> is nothing, then it's really just another name. >>>> >>>> So I would propose the following as there are already some branches out >>>> there which we all need to know and to handle. >>>> >>>> 5.0 will get all the fixes which will reflect in versions 5.0.x, commits >>>> will mostly get cherry-picked from master. Hopefully not that much. >>>> >>>> 5.1 will get at least the GTK+3 adjustments and will finally cover all >>>> versions 5.1.x (like 5.0 for 5.0.x). The GTK stuff is developed in this >>>> branch and will be merged into master. Any other changes than GTK+3 >>>> which should be released with versions 5.1.x are also made here and get >>>> merged into master. >>>> >>>> master is and will be the main nightly development channel. All changes >>>> here are mainly for any releases greater than 5.x.x. >>>> >>>> This all are just my thoughts as I would like to see it, the above >>>> suggestion is based on some experiences I have made with other projects >>>> and work. Please remember that also the l10n and documentation trees are >>>> related to this! The base for all future work for all side needs to be >>>> clear early as possible. >>>> >>>> Anyhow ... >>>> >>>> (Hmm, I don't wanted to a top posting but my answer wasn't fitting to >>>> any made statement.) >>>> >>>> Am 19.07.2018 um 17:19 schrieb Wayne Stambaugh: >>>>> 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 >>> 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
_______________________________________________ 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
