Audacious in current
 

Audacious 3.3.2 just came out. According to the developers, this is a bugfix release which fixes quite a few bugs. Too late to include it in 14.0?

Almost everthing is a bug fix release...

At this rate we'll never see 14. :( (Just kidding, of course, 14 will be AWESOME!) Just noticed there are more updates today. (Monday)

DNA
AKA mrascii

A short search in my Slackware64-current directory for *.txz reveals 1241 packages. If you assume one bugfix release per year per package (which is obviously unrealistically low for most packages) and they are well distributed over the year you would have about 3.4 packages a day with bugfix releases. At some point you simply have to make the stop integrating new bugfix releases.

I'm a firm believer in the old school of, "if it ain't broke, don't fix it," but I've spent enough time in the -current directories that, with all due respect, that just didn't quite sound correct to me, especially the part "...about 3.4 packages a day with bugfix releases."
I just went through the Slackware64-current repository, a through y, at Oregon State. I did it the old fashion way with pen and paper, making hash marks as I went along. This is approximate, as the old eyes crossed every now and then :) , but it is fairly accurate. There are 368 *.txz packages that haven't been updated in a year or more. Many of those, most I would say, are 2 to 4 years old. Of those, I was surprised at how many haven't been touched in 4 years.
That is fine with me, as I said above, "if it ain't broke, don't fix it," but your numbers didn't quite ring true. If you subtract all the KDE and KDE language packages which get updated with every release of KDE, and the packages in the new /xfce directory, for the same reason, you will see that a considerable number of packages do not get updated as often as one might think.
Cheers.

The real question would be: Are those packages only not updated in Slackware or are they not updated upstream also? Can you post some examples?

The only problem with asking for a package upgrade now is the timing for release I think. As soon as the release is made, -current can resume and we can probably get many more upgrades in it soon very easily by asking for a upgrade request.

It seems that all you got to do is post a request for a package upgrade that provides compelling evidence why it should be upgraded, here on the slackware LQ. Or, if it seems to be totally ignored here try to send the request to Pat once, then just wait because if the evidence seems poor then maybe nothing will happen for quite a while in -current. Evidence people want to see is for example, how the current package is failing you (error output), and changelogs from the package's development that shows it has fixed a serious bug, and other information that shows that the new package is much better and won't cripple the current users of old package when it is upgraded: test yourself upgrading to the package by building it and report on how it goes and if it impacted your configuration any, or was just a smooth upgrade. Try to test it and provide good details.

With slackware it is easy for you to make a package of your own to upgrade to. We have all those SlackBuild.org *.SlackBuild scripts that show you exactly how to make packages of all different kinds, and also the *.SlackBuild scripts in the Slackware distro source/ so you can rebuild packages in the distro just as they are built for release. You can find a SlackBuild for your package, or look at a slackbuild for a similar package and modify the slackbuild for the thing your are building. Okay... it is something like that.

Slackware is a lot Pat and his team, officially. But I think it can be a fair amount the users too if users are willing to do the work to show how and why a package will benefit from upgrade and not break the system some way. I'm sure there are a lot of years-old packages that are not upgraded. This is where the users of slackware can come in and test upgrading them and then provide good details on how upgrading worked out for them. The base a/, kernel k/, libraries l/, and development d/ sets are maybe most looked at during release development by the slackware team. User applications ap/ and xap/ are a bit more up to the users to test and suggest upgrade.

Sorry for long complex rant! The other thing with slackware is KISS (keep it simple, stupid). You know that is actually hard to do when working with complex systems like slackware and its packages, which happen to often not completely be KISS themselves. But anyhow, trying to write in a KISS style, minimal, but to the point will help get you noticed. I have to work on that myself! :)

The "if it ain't broke, don't fix it" is the prime reason for not recompiling or upgrading every package in the distro prior to releasing a new version.

For instance, yYou'll find that there is still almost 90 packages in Slackware 14.0 for x86_64 which have been compiled on my desktop computer in the attic at home... dating back from the time that slackware64 was not yet made public. There was no need to recompile them because they still work on Slackware 14.0 even though they were compiled before 13.0 was released.

That does not mean that all these packages will still compile from unmodified source, on Slackware 14! Chances are that many of those 85 would need to be upgraded or get gcc and glibc patches applied before they would compile into a new package.

Eric