Re: [GIT PULL] Thermal management updates for v5.4-rc1
On Fri, 27 Sep 2019 15:29:47 -0400 Doug Ledford wrote: > If you are doing linux kernel development, and you are doing a rebase, > please read Documentation/When_Not_To_Rebase.rst before rebasing your > code and sending it to Linus. You've been warned. For anybody following along at home, the proper spelling for that is Documentation/maintainer/rebasing-and-merging.txt or https://www.kernel.org/doc/html/latest/maintainer/rebasing-and-merging.html jon
Re: [GIT PULL] Thermal management updates for v5.4-rc1
Hi, Linus,
I'm really sorry about this.
I thought no code change could be a reason that a rebase can be
accepted, but didn't realize this is exactly the case we should avoid
it. I wish I could read Documentation/maintainer/rebasing-and-
merging.rst earlier so that I didn't make this mistake.
Sorry to bring this trouble.
thanks,
rui
On Fri, 2019-09-27 at 11:34 -0700, Linus Torvalds wrote:
> On Fri, Sep 27, 2019 at 6:08 AM Zhang Rui
> wrote:
> >
> > One thing to mention is that, all the patches have been tested in
> > linux-next for weeks, but there is a conflict detected, because
> > upstream has took commit eaf7b46083a7e34 ("docs: thermal: add it to
> > the
> > driver API") from jc-docs tree while I'm keeping a wrong version of
> > the
> > patch, so I just rebased my tree to fix this.
>
> Why do I have to say this EVERY single release?
>
> A conflict is not a reason to rebase. Conflicts happen. They happen a
> lot. I deal with them, and it's usually trivial.
>
> If you feel it's not trivial, just describe what the resolution is,
> rather than rebasing. Really.
>
> Rebasing for a random conflict (particularly in documentation, for
> chrissake!) is like using an atomic bomb to swat a fly. You have all
> those downsides, and there are basically _no_ upsides. It only makes
> for more work for me because I have to re-write this email for the
> millionth time, and that takes longer and is more aggravating than
> the
> conflict would have taken to just sort out.
>
>Linus
Re: [GIT PULL] Thermal management updates for v5.4-rc1
On Fri, 2019-09-27 at 21:52 +0200, Richard Weinberger wrote: > On Fri, Sep 27, 2019 at 9:30 PM Doug Ledford > wrote: > > Because there are literally thousands of developers working on > > kernel > > bits here and there, and you're swatting this particular fly one > > developer at a time. > > I strongly disagree. One of the golden rules of kernel development is, > read what Linus writes. Especially during the merge window. > > Thanks, > //richard Developers come and go. Your argument is temporally flawed. A developer might start working on the tree, read everything during a merge window, and not catch one of Linus' rebase rants prior to committing a rebase felony of their own. Besides, I don't think this rule of yours is all that universal. If Linus is off on a thread about arm64 device tree brokenness and someone does a rebase and he rants about it, I'm very likely to miss that rant. I read what I reasonably deem to be relevant to me and my work, or sometimes additional stuff that just jumps out at me. But I never learned to speed read so I don't even try to read it all and wouldn't agree to a rule that says I have to. -- Doug Ledford GPG KeyID: B826A3330E572FDD Fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD signature.asc Description: This is a digitally signed message part
Re: [GIT PULL] Thermal management updates for v5.4-rc1
On Fri, 2019-09-27 at 12:41 -0700, Linus Torvalds wrote: > On Fri, Sep 27, 2019 at 12:29 PM Doug Ledford > wrote: > > Because there are literally thousands of developers working on > > kernel > > bits here and there, and you're swatting this particular fly one > > developer at a time. > > Well, at least these days it's also very clearly spelled out in the > Documentation directory. Yeah, but let's be fair. How many people read the documentation fully? Or even if some new maintainer read it, did it really sink in? Or will they rebase a year later not thinking about it? > And the "don't rebase" does get posted on the mailing lists each time, > and I've mentioned it over the years in my release notes too. Lots of people here and there miss those things. You never know who caught what. > Besides, I actually only work with about a hundred top-level > maintainers, not thousands. Yes, we have thousands of developers, but > doing the stats over the 5.0 releases, there have been "only" 131 > people sending me pull requests. Sure, more than a couple, but at the > same time it's not like this is a "every developer" kind of thing, > this is literally subsystem maintainers. We've got a fair number of > them, but it's definitely not about thousands. > > I feel like I've sent that email out way more than a hundred times > over the last 15+ years. I'm sure you probably have. I think I got it two or three times before I got all the nuances of which rebases were OK and which weren't :-). > .. and I don't think having git warn is right, since rebasing is > perfectly fine as you are doing development. > > It's really just that maintainers shouldn't do it for bad reasons and > at bad times. > > And "there was a conflict" and "yesterday" is really one of the > absolute worst reasons/times around. I think you send it out a lot because it doesn't get driven home in people's heads until they get yelled at. And there's more to the badness of a rebase than just annoying you when you want to see the conflicts to judge things for yourself. There are legitimate issues such as a rebase wipes out history. Or if you rebase a public tree it blows up everyone that is tracking that branch. These things apply even to when you are doing your own development. Or rebases might wipe out merge commits from other trees, depending on options. A git warning solely for you might not truly be appropriate, but I'm not at all convinced that a git warning with a more general "Here are the pros and cons of rebases, with a list of dos and donts if you are going to do a rebase" document is a bad idea, and might actually help you out too. -- Doug Ledford GPG KeyID: B826A3330E572FDD Fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD signature.asc Description: This is a digitally signed message part
Re: [GIT PULL] Thermal management updates for v5.4-rc1
On Fri, Sep 27, 2019 at 9:30 PM Doug Ledford wrote: > Because there are literally thousands of developers working on kernel > bits here and there, and you're swatting this particular fly one > developer at a time. I strongly disagree. One of the golden rules of kernel development is, read what Linus writes. Especially during the merge window. Thanks, //richard
Re: [GIT PULL] Thermal management updates for v5.4-rc1
On Fri, Sep 27, 2019 at 12:29 PM Doug Ledford wrote: > > Because there are literally thousands of developers working on kernel > bits here and there, and you're swatting this particular fly one > developer at a time. Well, at least these days it's also very clearly spelled out in the Documentation directory. And the "don't rebase" does get posted on the mailing lists each time, and I've mentioned it over the years in my release notes too. Besides, I actually only work with about a hundred top-level maintainers, not thousands. Yes, we have thousands of developers, but doing the stats over the 5.0 releases, there have been "only" 131 people sending me pull requests. Sure, more than a couple, but at the same time it's not like this is a "every developer" kind of thing, this is literally subsystem maintainers. We've got a fair number of them, but it's definitely not about thousands. I feel like I've sent that email out way more than a hundred times over the last 15+ years. .. and I don't think having git warn is right, since rebasing is perfectly fine as you are doing development. It's really just that maintainers shouldn't do it for bad reasons and at bad times. And "there was a conflict" and "yesterday" is really one of the absolute worst reasons/times around. Linus
Re: [GIT PULL] Thermal management updates for v5.4-rc1
On Fri, 2019-09-27 at 11:34 -0700, Linus Torvalds wrote:
> On Fri, Sep 27, 2019 at 6:08 AM Zhang Rui wrote:
> > One thing to mention is that, all the patches have been tested in
> > linux-next for weeks, but there is a conflict detected, because
> > upstream has took commit eaf7b46083a7e34 ("docs: thermal: add it to
> > the
> > driver API") from jc-docs tree while I'm keeping a wrong version of
> > the
> > patch, so I just rebased my tree to fix this.
>
> Why do I have to say this EVERY single release?
Because there are literally thousands of developers working on kernel
bits here and there, and you're swatting this particular fly one
developer at a time.
I might suggest that you need to speak with the git people and politely
ask them to add a warning to the rebase command itself so that it prints
out something like:
If you are doing linux kernel development, and you are doing a rebase,
please read Documentation/When_Not_To_Rebase.rst before rebasing your
code and sending it to Linus. You've been warned.
Acknowledge receipt of warning and proceed with rebase? (y/N)
You would have free reign to put one of your more monumental yet funny
rants in place in the documentation.
You could also have a global git config to turn off the "Don't annoy
Linus with rebases" warning. But only mention that global config at the
end of the kernel documentation so you know people have read it before
they turn the warning off.
Maybe that would help.
> A conflict is not a reason to rebase. Conflicts happen. They happen a
> lot. I deal with them, and it's usually trivial.
>
> If you feel it's not trivial, just describe what the resolution is,
> rather than rebasing. Really.
>
> Rebasing for a random conflict (particularly in documentation, for
> chrissake!) is like using an atomic bomb to swat a fly. You have all
> those downsides, and there are basically _no_ upsides. It only makes
> for more work for me because I have to re-write this email for the
> millionth time, and that takes longer and is more aggravating than the
> conflict would have taken to just sort out.
>
>Linus
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
signature.asc
Description: This is a digitally signed message part
Re: [GIT PULL] Thermal management updates for v5.4-rc1
On Fri, Sep 27, 2019 at 6:08 AM Zhang Rui wrote:
>
> One thing to mention is that, all the patches have been tested in
> linux-next for weeks, but there is a conflict detected, because
> upstream has took commit eaf7b46083a7e34 ("docs: thermal: add it to the
> driver API") from jc-docs tree while I'm keeping a wrong version of the
> patch, so I just rebased my tree to fix this.
Why do I have to say this EVERY single release?
A conflict is not a reason to rebase. Conflicts happen. They happen a
lot. I deal with them, and it's usually trivial.
If you feel it's not trivial, just describe what the resolution is,
rather than rebasing. Really.
Rebasing for a random conflict (particularly in documentation, for
chrissake!) is like using an atomic bomb to swat a fly. You have all
those downsides, and there are basically _no_ upsides. It only makes
for more work for me because I have to re-write this email for the
millionth time, and that takes longer and is more aggravating than the
conflict would have taken to just sort out.
Linus
