On Wed, Aug 12, 2015 at 3:35 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Wed, Aug 12, 2015 at 12:10 PM, Alex Deucher <alexdeucher@xxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
