All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Yinghai Lu <yinghai@kernel.org>
Cc: Greg KH <gregkh@suse.de>,
	stable@vger.kernel.org, linux-kernel@vger.kernel.org,
	pjones@redhat.com
Subject: Re: [GIT PULL] ibft fix for 3.2-rc6
Date: Thu, 22 Dec 2011 22:50:25 -0500	[thread overview]
Message-ID: <CAPbh3rt_Fj-OcuH1mry3aUGQa+rc-t273KtWLSiQGpN1i2FtCQ@mail.gmail.com> (raw)
In-Reply-To: <CAE9FiQUvAv59UeCAyJ2h9swVmsbB6FqHzzThhbOhmvEag3WkRQ@mail.gmail.com>

>>> but that will add new feature to 2.6.32. Not sure if stable tree
>>> should take that kind of change.
>>
>> It could, but I am not too thrilled about it.
>
> RHEL 6.x are still with 2.6.32...
>

If Red Hat needs it, they can back-port it. It is not that hard for it
to be done and they are very proficient at it.

> So under UEFI mode installation, users need to input iscsi target info
> again during selecting storage for installation. Because kernel does
> not to parse that from acpi iBFT table.
>
> When legacy mode iscsi installation is used, installation program will
> not need user install those info again.
>
> QA are complaining that difference.

I think I understand your position. You are getting emails from QA
testing some hardware saying it does not work with RHEL, so you try
upstream, find the bug and fix it (awesome, thanks for doing that),
and then you want to back-port the fix so RHEL picks it up (and can
close the bug). Thr mechanism for that is by contacting the vendor
about this - either using the Program Manager to open a feature
request, or waiting for a customer to report this bug (on the Red Hat
side) and then your fix will be magically picked up.

The stable 2.6.32.x tree would require the sub-maintainer (that is me)
to sign off on supporting this in 2.6.32.x tree and I am not signing
up for it b/c I don't have the time to support it (this is after-work
hours fun stuff I do).

  reply	other threads:[~2011-12-23  3:50 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-15 21:05 [GIT PULL] ibft fix for 3.2-rc6 Konrad Rzeszutek Wilk
2011-12-15 23:15 ` Yinghai Lu
2011-12-16  0:07   ` Greg KH
2011-12-16  0:37     ` Yinghai Lu
2011-12-17  0:40       ` Yinghai Lu
2011-12-17 14:42         ` Konrad Rzeszutek Wilk
2011-12-17 14:42           ` Konrad Rzeszutek Wilk
2011-12-23  0:45           ` Yinghai Lu
2011-12-23  3:50             ` Konrad Rzeszutek Wilk [this message]
2011-12-23 18:24               ` Yinghai Lu
2011-12-22 20:58         ` Greg KH
2011-12-22 20:58           ` Greg KH

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=CAPbh3rt_Fj-OcuH1mry3aUGQa+rc-t273KtWLSiQGpN1i2FtCQ@mail.gmail.com \
    --to=konrad@darnok.org \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pjones@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=yinghai@kernel.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 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.