dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Kirill Smelkov <kirr@mns.spb.ru>
To: Ray Lee <ray-lk@madrabbit.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Luke-Jr <luke@dashjr.org>,
	intel-gfx@lists.freedesktop.org,
	LKML <linux-kernel@vger.kernel.org>,
	dri-devel@lists.freedesktop.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Pekka Enberg <penberg@kernel.org>
Subject: Re: Major 2.6.38 / 2.6.39 / 3.0 regression ignored?
Date: Tue, 9 Aug 2011 21:40:01 +0400	[thread overview]
Message-ID: <20110809174001.GA23408@tugrik.mns.mnsspb.ru> (raw)
In-Reply-To: <CADU53JVXiX2v+5N-VP8mz6vnxF60BYYXKV_PZQdd_U+qM5Gd6A@mail.gmail.com>

On Tue, Aug 09, 2011 at 09:56:01AM -0700, Ray Lee wrote:
> On Tue, Aug 9, 2011 at 9:32 AM, Kirill Smelkov <kirr@mns.spb.ru> wrote:
> > Quite frankly, I don't understand intel-gfx developers attitude: why is
> > it me, just random user who is nitpicking here? Why there is no
> > interest/will to analyze now obviously buggy/duplicate code and fix it?
> 
> Because they don't have an infinite amount of manpower. Actual bugs
> hitting actual users take precedence over 'cleanups' which always have
> a chance of causing regressions, as you're well aware. Code churn for
> the sake of abstract prettiness is discouraged, as it has a potential
> cost for little potential gain.
> 
> If you like, submit a patch. You may now be more up-to-date on those
> particular code paths than most of the intel-gfx developers.

Ray, I'd agree with you if the topic was about cleanups.

But here I was talking about copy-pasty commit which introduced
regressions and bugs, and if now it's a user dilemma to either "clean up"
it after developers himself, or accept that something is broken because
developers lack manpower and so plug things in a hurry increasing
entropy, I'd like to remind a good rule, at least to me one more time,
not to break things in the first place.

I'm not talking about cleanup here. I'm talking about original commit
which introduced problems, and that there is no need to clean it up, but
better revert and redo properly to avoid subsequent code churn in lots
of fixes.


Sorry, I won't submit a patch. If there is a need to find/fix/cleanup
obvious things after company's developers, I have better things to do,
and a todo item to re-evaluate hardware for my next project.


Thanks,
Kirill

  reply	other threads:[~2011-08-09 17:40 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-20 17:06 Major 2.6.38 regression ignored? Luke-Jr
2011-05-20 18:08 ` Ray Lee
2011-05-20 20:24   ` Rafael J. Wysocki
2011-05-20 21:11     ` Ray Lee
2011-05-21  8:41   ` Chris Wilson
2011-05-21 15:23     ` Luke-Jr
2011-05-21 15:40       ` Chris Wilson
2011-05-21 19:33         ` Luke-Jr
2011-05-28 13:19         ` Major 2.6.38 / 2.6.39 " Kirill Smelkov
2011-07-12 17:17           ` [Intel-gfx] " Kirill Smelkov
2011-07-12 18:07             ` Pekka Enberg
     [not found]               ` <CA+55aFxakA2U+oMJ1T7awTYa+p6xp9N0aCbfrUqgkF7BJ8gnQw@mail.gmail.com>
2011-07-22 11:08                 ` Major 2.6.38 / 2.6.39 / 3.0 " Kirill Smelkov
2011-07-22 14:12                   ` Herbert Xu
2011-07-22 18:00                   ` Keith Packard
2011-07-22 20:23                     ` Kirill Smelkov
2011-07-22 20:50                       ` Keith Packard
2011-07-22 21:08                         ` Kirill Smelkov
2011-07-22 21:31                           ` Kirill Smelkov
2011-07-23 15:10                             ` [Intel-gfx] " Alex Deucher
2011-07-23 18:19                               ` Kirill Smelkov
2011-07-23 15:55                         ` Pekka Enberg
2011-07-25  4:29                           ` Keith Packard
2011-07-26 13:48                       ` [Intel-gfx] " Kirill Smelkov
2011-08-09 12:08                         ` Kirill Smelkov
2011-08-09 14:00                           ` Vasily Khoruzhick
2011-08-09 14:47                             ` Kirill Smelkov
2011-08-09 15:09                               ` Vasily Khoruzhick
2011-08-09 15:34                                 ` Kirill Smelkov
2011-08-09 16:02                                   ` Vasily Khoruzhick
2011-08-09 16:32                                     ` [Intel-gfx] " Kirill Smelkov
2011-08-09 16:56                                       ` Ray Lee
2011-08-09 17:40                                         ` Kirill Smelkov [this message]
2011-08-09 17:43                                           ` Ray Lee
2011-08-10  8:36                                             ` Kirill Smelkov
2011-08-10  9:41                                           ` [Intel-gfx] " Alan Cox
2011-08-10 11:37                                             ` Kirill Smelkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110809174001.GA23408@tugrik.mns.mnsspb.ru \
    --to=kirr@mns.spb.ru \
    --cc=akpm@linux-foundation.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luke@dashjr.org \
    --cc=penberg@kernel.org \
    --cc=ray-lk@madrabbit.org \
    --cc=rjw@sisk.pl \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).