kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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
> 
>