> i doubt there will be much regressions in kernels of the same minor version
> ever.  especially ones which render kernel unbootable.

I've seen it happen, but very rarely during the stable maintenance period for
a release.  Those tend to have very conservative kernel upgrades.  Maybe once
several releases ago did I have a problem with a kernel update after final
release breaking my boot because of some weird hardware compatibility.

But let's agree that once a release is final, we probably do not need to keep
any old kernels around.  Before final release, I'd want to be less aggressive
in cleaning up old kernels by default.

> keyword will be "old kernel" - 1 is fine, especially if it's one from which
> update has been made.

How would you define "old"?  My definition would be "cruft as found by
computer-janitor" but for me that finds everything except the current running
kernel, so that's probably more aggressive than I'd want to be by default for
pre-releases.

>>For experienced users and those who participate in alpha testing,

> good for testers, not users.

Not even experienced users?  I certainly agree that it's all gibberish to most
"normal" users.

>>I think having those kernels around is very important.

> and i do not think so even for testers since they pretty much capable of
> reverting back after unlikely critical failure even if both "new" and
> "worked" kernels are broken by having 100% working version preinstalled
> manually or booting from live system or kernel from external device with
> initrd and 'root=<ubuntu root>' option

Those are all good emergency fall back options, but they're not nearly as
convenient as just booting a different kernel line.  If you're testing and get
a broken machine, I think it's better to have people up and running again as
quickly as possible.  E.g. you might not have created that external device and
may not be able to once your system is broken, or maybe the dog thought your
LiveCD was a frisbee and chewed it so it wouldn't boot. :)

My point is that in general, anybody who's testing a new Ubuntu release should
be prepared for more details, less polish, etc. and extra kernel lines should
not be confusing at all.  Well, unless their testing a better boot
menu. <wink>

>>Those folks won't mind all the extra lines of gibberish.

> those folks can handle a lot of crap life can throw at them, i have no doubt
> about that.  but, being gentoo user myself, i do not appreciate useless stuff
> lying around even though i reboot my home systems no often then once per 2
> weeks. and i cannot comprehend how it can be frustrating for "normal people"

I'm a gentoo user too (still have one gentoo server) and I very rarely reboot
either that machine or my stable Ubuntu servers or desktops.  Cleaning up
useless stuff is the job of Computer Janitor on Ubuntu so I think that's the
proper tool to use for those who want a nice tidy system.

> new grub2 widget-like graphic menu may look fancy but probably will not
> include any crutches for hiding ranges of kernels with same root-option. just
> keep it simple, please :(

I think that would be the whole point of redesigning the boot menu
experience.  I'd like to get some thoughts from the design team on that
though.  I'm sure they can come up with something that works great for
non-experts but provides a good escape or fall back for experts.

A bug report on update-manager is not the best way to get that input regarding
the boot menu.

> PS: "people" do not report two issues here, it just someone with too long
> hands is marking reports about menu and space as duplicates :\ but since
> those useless kernels clutter both menu and space it better to "kill two
> hares with a single shot"

The original bug description was about space.  It wasn't until comment #4 that
the issue of accidental kernel selection comes up and not until comment #14
that the issue of boot menu clutter comes up.

I think it's important to keep the issues separate because IMHO the solutions
are different.  For example, even if we cleaned up all old kernels in Update
Manager, I don't actually think that would improve the boot menu experience
much for most non-expert dual-booters.  For example, I'm looking at the boot
screen for my dual-boot machine running Windows 7 and Lucid beta (upgraded
from Karmic).  I can promise you my mom would have no clue what any of this
means:

            GNU GRUB version 1.98-1ubuntu2

Ubuntu, with Linux 2.6.32-16-generic
Ubuntu, with Linux 2.6.32-16-generic (recovery mode)
Memory test (memtest86+)
Memory test (memtest86+, serial console 115200)
Windows Vista (loader)

    Use the ^ and v keys to select which entry is highlighted.
    Press enter to boot the selected OS, 'e' to edit the commands
    before booting or 'c' for a command-line.

Man, I sure hope mom never tries to hit 'e' or 'c' or I'm getting a support
call from my second most important customer (my wife being #1 :).  Note that
this menu doesn't even tell the truth - I upgraded Vista to Windows 7 months
ago so why is it giving me the option to boot an OS I don't have any more?

All of this is with just one kernel installed.  You can't reduce the clutter
any more by removing old kernels.  But I do think that you could make this
boot menu /much/ more user friendly.  It's just not something that's within
the mission of Update Manager (where this bug was originally reported).

I still think providing a bit of info and a button for CJ solves the OP, and
some guidance from the design team would help a lot for making the boot menu
comprehensible to normal users.  The latter should be handled in a bug report
about boot menu clutter.

Cheers.