Minidisk support (was: Installation Question)
(No need to CC me; I read the list; see the Debian mailing list policy.)
Hello Stephen,
A few misconceptions in your mail. Let me try to correct them and offer
some advise on who to proceed.
But first of all: please don't hijack an existing thread for an unrelated
issue; next time, please just start a new thread instead.
On Monday 14 December 2009, Stephen Powell wrote:
> Given the low frequency of stable release updates,
You are mixing two different things in this mail:
- the next stable release (Squeeze)
- the next update (point release) for the existing stable release (Lenny)
The rules, limitations and methods for getting changes included are
completely different for them, and you should clearly separate between
them.
> perhaps I should ask if the fix for Debian bug #550898 is scheduled to be
The people to ask are the kernel team. And for inclusion in a stable
update, you may need to specifically need to make the person within that
team who takes care of preparing those updates (Dan Frazier) aware of the
issue.
Bastian Blank as kernel team member and s390 porter would be a logical
person to drive this, but possibly he does not personally think the issue
important enough to get involved. I don't know.
> included in the next update, both in the Debian installer and in the
> regular stock kernels.
There is no difference between regular and D-I kernels, especially not for
the next stable release. D-I merely repackages the regular kernel into
udebs it does not build its own kernels.
So, any change included in the regular kernels almost automatically gets
included in the installer (except when it requires additional new kernel
modules to be included, which is not the case here).
For stable updates it is a bit different as not every point release
includes an update of the Installer, and even if the installer is updated,
it does not necessarily include a kernel update.
> This fix is an s390/s390x-specific fix. An upstream developer
> promised me that he would get this fix in the next kernel release, which
> at the time was going to be 2.6.33.
Right. The fix (22825ab7) _is_ now in mainline, which means your chances of
getting this included in Debian Squeeze has just increased from 10% to
about 98%. And the chance to get it included in Lenny from 0% to 20%.
Why? Simple. The kernel team policy is to only include patches that already
have been accepted upstream or look certain to get included upstream very
soon.
For stable updates added criteria are:
- it must fix an important *bug* (affecting a significant number of users),
or
- it must be an enhancement that is very important to a significant number
of users *and* has no risk of introducing regressions.
This patch is IMO more an enhancement than a bug fix, so I'm not certain it
qualifies for a stable update.
> But since stable Debian releases
> tend to go with even numbered kernel releases, the earliest upstream
That is a totally random deduction based on nothing else than coincidence
for the last few releases. There is no difference between odd and even
upstream releases, so no reason for Debian to prefer even ones. The choice
of kernel version is mostly a timing issue (when is the upstream release
relative to Debian's freeze date) and possibly what kernel other
distributions use for their releases (so we can profit from long term
maintenance of that kernel release).
> version which contains this fix that Debian actually uses is likely to
> be 2.6.34.
So this is nonsense.
> That might not even be available in Squeeze. I'd really like to see this
> fix in production as soon as possible.
I don't know what the kernel team are currently planning for Squeeze: .32
or .33. It depends a lot on when Debian actually freezes. I guess .32 is
more likely than .33, but .33 is a possibility.
Now, assuming that it will be .32, how can you get this fix that's been
included upstream in .33 included in Debian?
By far the best way is to try to get *upstream* to include the patch in one
of their "stable updates" for .32, so in 2.6.32.1 or 2.6.32.2. I would
suggest proposing that on the linux-s390 mailing list.
If that does not happen, you can try asking the Debian kernel team to
backport the fix to .32. The way to do that is:
- follow up to the bug report
- include a link to the upstream commit in .33 (this is essential!)
- get the attention of the kernel team: keep following up regularly and
ask (politely) if someone has had a chance to consider this
To get the patch included in a Lenny point release you need to do the same,
but with the following additional things:
- provide a solid rationale why this is an important change for Lenny
- check whether or not the upstream patch applies to the current Lenny
kernel
- if it does, test it thoroughly
- if it does not, provide a backported patch after testing that thoroughly
- make sure the maintainer for the stable kernel is aware of the issue
As mentioned before, I'm not sure that this qualifies for Lenny. Any
backport is a risk and the number of users that will benefit is uncertain,
but likely to be low. It might be different if other users spoke up...
Is it worth the effort?
> Until that happens, I will have to build custom kernels.
This is never going to be an argumentation that convinces anybody...
> I requested this in bug report number 550898, but no-one responded.
That is probably because:
- s390 is not one of the most important arches for Debian
- the kernel team is small and already has a huge workload, so things
that are on the fringe easily get missed or skipped
- in your original mail you failed to provide an actual patch people could
review (instead you posted two blobs of code which they'd need to compare
manually)
- until now your patch did not meet the criterion of being accepted
upstream
Hope this helps,
FJP
Reply to: