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