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".
Linus
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
