lkml.org 
[lkml]   [2010]   [Jun]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [git pull] drm fixes


    On Tue, 8 Jun 2010, Dave Airlie wrote:

    > >         26 files changed, 372 insertions(+), 66 deletions(-)
    > >
    > > and there are apparently several reports of known problems (the problem
    > > with modesetting) that isn't even addressed.
    >
    > Okay, not sure what the addressed regression you are talking about, do
    > you want regression fixes early like you always say or do you want to
    > wait until I have every regression reported fixes before I send a pull
    > request?

    I absolutely do want regression fixes early. If they've been verified to
    fix something, I do want to merge them as soon as possible.

    But EVEN MORE IMPORTANTLY - and the point of me saying no - I do _not_
    want non-regression fixes mixed in. Which clearly was the case here. So
    "as soon as possible" does not mean that I'll take _other_ things just to
    get the fix. The regression fix should stand on its own - and be merged
    on its own.

    So no, it's not an excuse to send me a tree that contains other crud, and
    then use ".. but but you wanted regression fixes" as the excuse for
    sending those other changes too.

    The whole point of the merge window is to then _after_ it closes no longer
    merge new code.

    > I really hope you do this, if I find one thing going into your tree
    > after today that isn't a regression fix I'll send revert patches if
    > that'll help.

    I don't like seeing revert patches unless they revert something that is
    buggy. So no, "revert because I shouldn't have sent that commit" is not a
    good policy. If I end pulling something, it's my bad, and I won't revert
    it just because I made a mistake - it needs to be somehow actually be
    involved in some real problem.

    But I _am_ trying to be proactive about problems during this particular
    release cycle.

    The point I'm trying to make is that I am going to be strict about the
    rules (the ones we've had for several years now, but people tend to be a
    bit loose about). I _should_ probably be stricter than I usually am even
    normally, but this time I am going to be very strict for -rc3 due to
    being away for part of the release cycle.

    And no, don't worry - it's not just for you. I already rejected a
    microblaze pull for all the same reasons, and asked for some extended
    clarifications for a (much smaller) jffs2 pull despite the fact that we've
    generally not had lots of problems with jffs2.

    Linus
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2010-06-07 23:01    [W:0.024 / U:30.868 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site