[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 

> 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 

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 

For stable updates added criteria are:
- it must fix an important *bug* (affecting a significant number of users),
- 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 or 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
- 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
- until now your patch did not meet the criterion of being accepted

Hope this helps,

Reply to: