On Tue, Jul 18, 2017 at 12:07 PM, Doug Ledford <dledford@xxxxxxxxxx> wrote:
>
> Fair enough. My branch still had two unpulled commits and was based on
> v4.12-rc3. But, you had already taken the SELinux/RDMA patches through
> the SELinux tree during this merge window, and two of the fix patches
> in my pull request would have produced conflicts for you if I didn't
> merge up to a common ancestor that had the SELinux/RDMA patches prior
> to applying those patches to my tree (these two in particular):
Please don't worry about conflicts, unless they are something really
really fundamentally hard to merge. And even then, for rdma, I
probably want to see them, just to see what the hell went wrong *this
time*.
>> And if the only reason for that merge is "sync with upstream", then
>> no, that is not a sufficient reason. It has to have an actual real
>> reason, and it needs to be stated.
>
> Does this apply to the for-next area as well?
Largely, yes. Because the further away "for-next" gets from what you
then eventually send me, if your for-next branch has odd useless
merges, then either what you send me will have them too, or what you
send me will be something entirely different and rebased.
Basically, "automated merges" is wrong and bad. The ACPI people used
to do them, and at some point their pull requests had more merge
commits than they had actual changes.
Merges should be generally *minimized*. They make it much harder to
see what is actually your new independent work, and what is work that
is on top of random other things.
Regular automated merges is exactly the wrong thing to do, because it
basically guarantees that you don't have a nice stand-alone
development series (everything you do will be punctuated by those
merges), _and_ that the merge commits are bad and have no good reason
for them.
Finally, the merges have a fundamental problem that is from past
problems with rdma - in particular the history of mixing stuff up and
having teams within one single company not even being able to talk or
synchronize with each other.
If you need merges for conflict resolution, it indicates to me that
rdma *still* has that issue where people fight over the direction and
the drivers between different teams.
So while merges in general are something that should be avoided, when
it comes to rdma in _particular_ I don't like seeing them, because I
get the feeling that they are papering over the nasty development
problems you guys have had, and are done as a way to handle the
conflicts that were due to bad hygiene.
So the *one* kind of merge that is good is the "development of this
topic branch is finished and done, let's merge it up". But that is
never about time, that's about "I'm done with this series, it's good
to go into my main branch". That's a "forward merge", where you really
merge the new and finished development tree into the base.
The back-merges, when you merge some unrelated development, is
generally a bad sign. It inevitably happens for various reasons, but
it should be seen as the exception, not the rule, and it should
*always* have an explanation.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
