All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Andi Kleen <andi@firstfloor.org>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	tglx@linutronix.de, linux-kernel@vger.kernel.org,
	venkatesh.pallipadi@intel.com, "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH] Fix early_ioremap on x86-64
Date: Mon, 21 Jan 2008 01:20:41 +0100	[thread overview]
Message-ID: <20080121002041.GA31280@elte.hu> (raw)
In-Reply-To: <20080120191247.GA28190@one.firstfloor.org>


* Andi Kleen <andi@firstfloor.org> wrote:

> > Jeremy did suspect something about this change, as indicated in the 
> > changelog. But because the change was so finegrained, the bisection 
> > almost directly led to the fix. _That_ i think clearly demonstrates 
> > the power of bisection and finegrained changes.
> 
> Actually it is pretty hard to do bisects in current git-x86 currently 
> because you don't ammend original buggy changes but just stuff the 
> fixes at the end. [...]

i backmerge fixes all the time. x86.git consists of more than 800 
patches and there are less than 10 tail-fixes in it - they are all at 
the tail for a reason: because they have not all been fully qa-ed yet so 
they might make things worse than what they try to fix. Once they are 
proven i backmerge them to their proper spot.

and i frequently bisect x86.git#mm myself (almost daily) - and others do 
it frequently too. There have been dozens of successful bisections done 
on x86.git. (I believe it is so successful partly because we run 
overnight automated bisectability tests: to make sure x86.git builds and 
boots at every bisection point.)

Yours is the first claim of x86.git#mm being hard to bisect - so far all 
other feedback was to the contrary. I claim that it is one of the most 
bisectable subsystems in the kernel.

But we all err: if something slipped through despite all the testing, 
let us know and we'll fix it up - it's just that your vague complaints 
about non-bisectability wont help much in resolving the problem. You are 
ignoring months of track record of excellent bisectability of x86.git 
and your claims are quite unjust.

Reordering of patches is usually easy and trickling back the tail-fixes 
to the actual buggy patches is easy and routine as well, except when 
someone submits conceptually non-bisectable patches, like:

|   Subject: Undo pat cpa patch
|   From: Andi Kleen <ak@suse.de>
|
|   Going to implement this differently

and then 4 patches later you do:

|   Subject: CPA: Implement change_page_attr_addr entry point for i386
|   From: Andi Kleen <ak@suse.de>

this breaks PAT completely in that window and makes it non-bisectable.

So i find it a bit dishonest from you that you are now complaining about 
the supposed non-bisectability of x86.git ...

> -Andi (seemingly chief QA officer of git-x86 currently)

Andi, could you please stop these snide remarks? x86.git is the 
development tip of the new arch/x86 tree and you should know that. I 
boot it more than a 1000 times a day on my QA-grid, with different 
kernel configs, so it's far from being unusable.

I update x86.git multiple times a day so that people can see the changes 
immediately. But you are now abusing this transparency to create a false 
impression of flakiness. If you cannot stop being negative then please 
just dont deal with x86.git#mm - it's not obligatory to contribute.

Furthermore, your complaint is doubly unjust because we've fixed a good 
deal of bugs in x86.git introduced by _you_. You are by far not the only 
person who fixes bugs in x86.git and you are by far not the most active 
one either - but you are certainly the loudest one :-(
 
	Ingo

  reply	other threads:[~2008-01-21  0:21 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-20 17:28 [PATCH] Fix early_ioremap on x86-64 Andi Kleen
2008-01-20 17:59 ` Ingo Molnar
2008-01-20 19:12   ` Andi Kleen
2008-01-21  0:20     ` Ingo Molnar [this message]
2008-01-20 18:04 ` [PATCH] Fix early_ioremap on x86-64 II Andi Kleen
2008-01-21 19:00   ` Jeremy Fitzhardinge

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=20080121002041.GA31280@elte.hu \
    --to=mingo@elte.hu \
    --cc=andi@firstfloor.org \
    --cc=hpa@zytor.com \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=venkatesh.pallipadi@intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.