kicad-developers team mailing list archive

[Carsten Schoenert <c.schoenert@xxxxxxxxxxx>]

Am 25.07.18 um 17:40 schrieb Maciej Sumiński:
> Nobody forbids working on new features in separate branches that we will
> start merging once 5.1 is released and 6.0 development cycle starts. I
> have already started a few branches for v6 features, but they need to
> wait now.

That's what I mean, why I need to wait? In recent days this is for me a
mismanagement and such things are mostly not needed. Those are feature
branches made for so people can continue on their work continuously. You
will need to merge the related changes into the other branches.

Remember the link to the website I made, it show this nicely.

https://nvie.com/posts/a-successful-git-branching-model/

> I simply rebase them from time to time, but it is not a big deal so
> far.
This will get annoying and frustrating the more often you need to do
this. It may be not a big deal for you as a core developer because you
know mostly every detail in the source, but for people from outside it's
unneeded load to do such rebasing again and again. I've done this for
thunderbird for about a half year before I was going further. This was
really frustrating.

> I anticipate GTK3 fixes to be ready in 1-2 months from now,
> I am not sure if the delay is significant enough to keep this discussion
> going on.

This is a decision you have to make. For me GTK fixes are a thing you of
course will need to have also in later version so the typical solution
is to merge theses things into the current master branch. No need for
cherry-picking.

> We have already experienced a significant overhead in late v5 cycle due
> to porting certain v4 fixes to v5 branch or vice versa. Imagine that we
> keep working on 5.1 and 6.0 at the same time.

I know such things from other projects, this is real life. Other
projects have people which are responsible for release management.

> I am sure we could right now dump enough code onto the 6.0 branch to
> diverge it from 5.1 so much that porting fixes between them becomes
> non trivial. Keep in mind that there is 5.0 branch that may need to
> share some patches with the remaining branches too. Please notice
> that *every* patch that we applied to 5.1 had to be applied to the
> master branch as well via cherry-picking.
You really wont do cherry-picking! Merging is the right thing here.
KiCad is not the Linux kernel or Gnome, but look how these projects are
working. Both need to take care about older releases too. And many other
projects also.
If you keep up the branches in the core in sync it isn't that difficult
to backport changes.

> What are the benefits of maintaining 3 branches?

Simply that every one can make progress without being slowed down due
some technical reasons? It's all about organization.

In the long run you will need at least two branches like before, so
currently you will need also 5.0 to provide urgent fixes before any
5.1.x release is made. It's not that much more I guess.

But again, it's up to you guys how you will organize your work, all from
me are just suggestions based on experiences I made in the last decade
while contributing to various projects. Let's stop here.

-- 
Regards
Carsten Schoenert