[pull] radeon and amdgpu drm-fixes-4.2

[Alex Deucher]

On Wed, Aug 12, 2015 at 3:35 PM, Linus Torvalds
<torvalds at linux-foundation.org> wrote:
> On Wed, Aug 12, 2015 at 12:10 PM, Alex Deucher <alexdeucher at gmail.com> wrote:
>>
>> I always rebase my pull requests against Dave's drm-fixes tree before
>> I send a pull request.  Since he's out of town I rebased against your
>> tree.  I didn't realize that was not the preferred model.  I thought
>> it was preferred to fix up any possible conflicts that may arise from
>> other changes in the subsystem tree (although are pretty unlikely).
>
> Yes, absolutely not. Rebasing generally doesn't fix up any conflicts,
> it just means that you're moving to a new base and throwing away a lot
> of the testing you did.
>
> Generally, the preferred model is:
>
>  - strive to base your development on a well-characterized base (for
> example, a previous release), and _stay_ on that base (ie don't get
> distracted by what other unrelated development projects are doing).
>
>  - do *not* rebase of pull from upstream (Dave or me), particularly
> durign the merge window, since all you are doing is just bringing in
> development work that is entirely irrelevant to _your_ development
> work, and potential instabilities from other sources.
>
> The only real reason to ever rebase is if your code and testing is
> being impacted by bugs or lack of features that the rebasing fixes -
> iow you actively need the rebase in order to make progress on
> development and testing. Otherwise, rebasing only hurts.
>
> You do generally want to make sure you don't stay *too* far behind, of
> course, and rebasing can be the solution to that, but that's very much
> not a "before sending a pull request" thing, because now you've lost
> the "this has been tested extensively" advantage (which I obviously
> _hope_ you had at some point).  And "too far behind" is more about to
> "two releases behind" than "yesterday's tree" kind of behind.
>
> So by all means rebase, but rebase to clean up ugly history, or to get
> a better base for development. Both of which are good things. But when
> you do that, realize that it means you are cleaning up and to some
> degree starting from scratch, so it's now a *new* base for testing and
> development, not a "let's send this upstream immediately".
>
> I hate pulling stuff that I can see has not been well tested. I want
> to at least be able to fool myself into thinking that downstream has
> really worked hard at validating what they send me.
>
> Yeah, yeah, I realize that not everything I get is well tested. I'm
> not _entirely_ delusional. But please let me at least have that small
> hope that what I pulled saw some testing, ok?
>
> And like always: there are very few totally black-and-white rules.
> Sometimes rebasing before sending stuff to me is valid: you realize
> there was some bad problem you want to fix up, and the downsides of
> rebasing are smaller than the upsides. But while rebasing before
> sending things upstream _can_ be valid, it definitely shouldn't be the
> "normal development model".

Ok, thanks.  I'll keep that in mind going forward.  Any yes, these
patches have been tested fairly extensively inside AMD.

Alex