[infinispan-dev] Branching proposal

[Dan Berindei]

On Mon, Mar 27, 2017 at 2:51 PM, Sebastian Laskawiec
<slaskawi at redhat.com> wrote:
>
>
> On Mon, Mar 27, 2017 at 1:05 PM Sanne Grinovero <sanne at infinispan.org>
> wrote:
>>
>> You need to make sure you optimise for engineers coding stuff which
>> works on master, not maintenance.
>
>
> Well it depends on your strategy. Note that with my proposal you can always
> do that (optimize features for development not for maintenance).... just put
> your PR on master branch. That's all...
>

The problem is that my master-only changes will also make your
maintenance changes harder to merge into master. Would you be willing
to cherry-pick others' commits into a maintenance branch just to make
your pull request apply cleanly to both branches?

> The proposal is all about making maintenance easier. Development stays the
> same.
>
>>
>> Isn't it a bit naive to expect people to work on the "last maintained
>> branch" ?
>
>
> I don't think so. In that past I worked on a project with 3 maintenance
> branches plus a development branch. It worked. That's why I'm proposing this
> here.
>
>>
>> Your proposal expect that each and every patch author:
>>   a) knows for sure it's not going to be backported further to even
>> older branches
>
>
> As I explained this to Radim, occasional cherry-picking is totally fine.
> During the merge git will look at the commit, say... oh this commit is
> already there and move on.
>

Unless the commit was already modified because of a conflict...

>>
>>   b) you're not investigating issues on master (as investigation often
>> implies making code changes already)
>
>
> Again it depends. If you do not care about maintenance branches, you can
> still code at master branch.
>
> I also disagree with you here. We should always fix errors where they occur
> and not only in maintenance branch. If the failure is on 9.1.x branch, then
> the fix should go there. Not to master.
>

I agree with Sanne. If there's already a 9.2.x branch, I really don't
want to look into all the previous releases to see if it also
reproduces there. I may not even check if it's reproducible on 9.2.x,
if I know the 10.0.x release is coming "soon".

>>
>> Both of these are not very practical as I generally don't expect to
>> backport each and every fix, and it's going to be someone else to
>> recommend/approve some backports *after* the problem has been
>> understood in depth.
>
>
> In that kind of workflow my proposal wouldn't work well. I'm also a bit
> curious, how often do we need such an approval?
>

At least in my case, I'd call it "prodding" instead of "approval", and
it happens fairly often.

>>
>> You even mention "forgetting to backport refactoring" ? Hell yes you
>> should never backport refactorings..
>
>
> It depends. How about our checkstyle changes? After some time I guess I
> should have backported them to make cherry-picking easier.
>
>>
>> What I'm reading here is that you're all doing way too many backports.
>> Be more conservative about them?
>
>
> That's a very well stated question. My proposal makes the maintenance easier
> but developers need to be a bit more responsible (they need to know in which
> branch to implement a given fix and remember about doing merges). On the
> other hand if we prefer to encourage our users to move to more recent
> version quicker, than it probably doesn't make much sense.
>

IMO we should never have more than one maintenance branch in which we
do regular backports. We may have to do the occasional backport into
older branches, but that should be the exception, not the rule.

>>
>> In my experience with recent contributions to Infinispan - either
>> because the testsuite is slow, or because it takes us too long to
>> figure out there has been a regression, I sent a PR to master and two
>> maintenance branches but I had to repeat the exercise two more times
>> to add follow up fixes on the same subject: if I had waited on
>> backports it would have taken me a third of the time.
>
>
> Note that my proposal partially addresses this concern. Individual PRs
> wouldn't need to go through CI loop but they would be merged in batches. On
> the other hand, even an easy merge might break the build.
>

-1000 to blind merges, the master build is broken enough as it is.

Cheers
Dan