kicad-developers team mailing list archive

[Carsten Schoenert <c.schoenert@xxxxxxxxxxx>]

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


-- 
Regards
Carsten Schoenert