ECN [LWN.net]

ECN

Posted Oct 28, 2008 0:11 UTC (Tue) by ncm (subscriber, #165)
In reply to: ECN by dlang
Parent article: Stable kernel 2.6.27.4

"They", who did not follow the RFCs, refers to whoever coded the routers.

Delaying the release, or going with a better-tested, older kernel, are both sane options. "Release Candidate" really shouldn't the considered the same as "release version", and problems found in one really should be fixed properly before release. Otherwise what's the point? Delays are embarrassing, but that's because bugs are embarrassing. Bugs are even more embarrassing if you fail to fix them.

More proof that the lessons won't be learned.

(Log in to post comments)

ECN

Posted Oct 28, 2008 0:42 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]

which 'They' are you referring to?

the 'They' who introduced and didn't find the bug followed the RFCs

the 'they' who are doing the ubuntu release need to balance the problems that this problem can cause with all the fixes that are in the 2.6.27 release (including the support for some very common wireless hardware)

you say that they should go with a 'well tested older release', but if they didn't do the testing of that older release is it really any better than the current release? or than going with the untested -stable release?

ECN

Posted Oct 28, 2008 1:01 UTC (Tue) by nick.lowe (subscriber, #54609) [Link]

Sorry, I do have to question:

"balance the problems that this problem can cause with all the fixes that are in the 2.6.27 release"

What!?

I would be fascinated to know what you think "the problems that this problem can cause" are?

The commit is http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-...

Yours in anticipation! :)

ECN

Posted Oct 28, 2008 2:06 UTC (Tue) by ncm (subscriber, #165) [Link]

Please read the posting you are replying to. 'They' is who I said it was: "whoever coded the routers".

Considering the details of the patch, the additional testing needed to verify a patched kernel is minimal -- certainly less than what was needed to verify the cheesy procps workaround with the present kernel.