kicad-developers team mailing list archive

[Jeff Young <jeff@xxxxxxxxx>]

+1

> On 24 Jul 2018, at 08:01, Maciej Sumiński <maciej.suminski@xxxxxxx> 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.beard@xxxxxxxxx
>>>>>> <mailto:john.j.beard@xxxxxxxxx>> wrote:
>>>>>> 
>>>>>>    On Thu, Jul 19, 2018 at 1:47 PM, Wayne Stambaugh
>>>>>>    <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
>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : 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
>> 
> 
> 
> _______________________________________________
> 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