I say go back to 3.2.x for the kernel and move up to 3.9.x for /testing.

That is because -- assuming 14.1 were released today, which you HAVE to do when maintaining a tree that could at any arbitrary time potentially be freezed for the next release -- it is STILL projected to be EOL'd later than any of the other Kernel trees at this juncture.

See https://www.kernel.org/category/releases.html for more information.

The other alternative is to delay the release for a further period of time (targetting a 15.0 rather than a 14.1 release, as many people have pointed out as a possibility) and wait for the next version of the kernel that is projected to be supported longer than 3.2 already is.

That's my opinion, anyway. The server always needs to be looked at as the lowest common denominator for a general purpose distro with an emphasis on stability such as Slackware.

Slackware stuck with 2.4.x for years because, among other reasons, it was stable, maintained, and a rock-solid choice for servers.

If Slackware goes with 3.4 or 3.9 or any other branch that is only going to be maintained through 2014, I'll be skipping 14.1 on my server but will be looking forward to the upgrade on my desktop machine.

On 2) and 3) I have no opinion. I'll defer to the BDFL on those.

Going back to 3.2.x is not an option due to the severe bug between that kernel and udev that leads to long boot time delays. Plus, I think the people who would like to see a retreat back that far are a severe minority.

If someone wants to run 3.2 when the support for 3.4 or 3.8 runs out, nothing is stopping them. But, it makes no sense to ship a kernel that old when there are better options available. It wasn't that long ago that LTS kernels didn't exist at all, and somehow we all survived.

On the other side of the coin, wouldn't someone wanting support for that long just be able to stick with the 14.0 release?

1 members found this post helpful.

I wasn't aware that was an issue, but yeah, that is probably a showstopper. :-(

Is that only an issue when newer versions of udev are combined with 3.2.x?

Knowing that information, I do agree that 3.4 is probably the best option (Lesson: never distrust the BDFL ever again). 3.9.x in testing/ would still be nice, but not a priority as folks can always compile a newer kernel for themselves.

I suppose that's true, but I feel that in the 2.4 days, things weren't aggressively changed as much and if a newer 2.4.x needed to be put into /patches for security reasons, it was a relatively smooth upgrade. Maybe I'm just looking at the past through rose-coloured glasses, as is my wont.

If 3.4.x were EOL'd before Slackware 14.1 was intended to be, and a major security issue were detected with the 3.4.x kernel shipped with 14.1, would you try to backport the security patch from a newer kernel?

Nope. With some drivers it is a problem in 14.0, but there wasn't a fix (we looked), so we had to live with it there.

I'd have to agree that the way 2.4 evolved didn't place people on the bleeding edge as often, but due to the way Slackware's 2.4 kernels were compiled at the time, upgrades of 2.4 were pretty nightmarish on this end. There were a lot of kernels for various SCSI controllers then, not just a huge and generic kernel.

If it's major (like a remote root), certainly yes. It's been done in the past, sometimes even for local root issues like the mmap zero page.

3.2 was also the cause of hard lockups on my laptop [i5 with Ivy bridge]. I don't know what the problem was, but it has certainly been fixed in later versions.

I like 3.8, which is stabilizing nicely now. A reversion to 3.4 is also a step too far backwards, IMO.

Patrick what about inclusion of an alternative to udev like hotplug2 in /testing?

3.4.x as the default kernel is the best course of action, while 3.9.x should be moved into /testing. As with the previous sentence above regarding hotplug2, maybe udev can be worked around if it gets problematic, or even replaced with something more viable.

Feel free to submit a package that includes a complete set of working rules.

2 members found this post helpful.

Hopefully whichever kernel version you pick Pat, the kernel modules for the intel GPU's are better or at least on-par with the 3.2 series (tried 3.4, 3.6, 3.7, 3.8 and 3.9, for some reason they all result in about 33% less FPS than the 3.2.29 kernel).

That's not same result I get!

That's the result I get using many programs with the intel GPU part of my nvidia optimus laptop. Perhaps it may not apply to those who have only an intel GPU.

What is the state of the USB 3.0 xHCI stack in 3.4 vs. 3.8? I heard of many improvements since 3.2, where it is only barely functional.

In that case, I now have no opinion on (1), (2) or (3). :-P

Initially my thinking was that we might be placed into the extraordinary possibility of Slackware 14.0 being in a position to be supported up to a later date than 14.1.

1. Linux 3.4 as the well tested branch with planned long time support is currently an optimal choice. However I'd also vote to put more recent version (> 3.8.4) in testing/ as already suggested. Hope it won't be too tiresome and time consuming to keep it updated. As 3.4.x do work well, there are noticeable benefits mostly on some kind of (recent) hardware like broader chipsets support, fixed very annoying power-management regressions (although introduced in late 3.5/early 3.6 versions, some issues from 3.4 were also fixed), better support for dual graphics adapters (like nVidia's Optimus) etc.
2. Keeping GCC branch of 4.7 also find a wise decision. I don't see any significant benefits to use 4.8 now. Not enough tested, introduces a few incompatibilities and some of upstream sources not yet adapted and won't compile without a home-brewed patch etc. Also most of major distributions do use 4.7 as their default currently.
3. By similar reasons mentioned in the previous paragraph, I'm also giving nods to Your suggestion and would prefer to keep Xorg at 1.13 version. Although avoiding closed-source sw as possible, some of them (proprietary vga drivers, commercial games, etc.) are linked/tested with not the most recent X & OpenGL libraries so with 1.14 some may not run (properly). As a nice bonus backported drivers (bugged intel's especially) packaged in testing/ would be welcomed.

Keep the great job.

Take care

In my case I can say any versions before 3.6 don't work. The inplug event can be detected, but the device can't connect to the xHCI.

And bacause versions >=3.8 crashes 100% of the times disconnecting from bluetooth modem, I am stuck to 3.7.10 currently.