Re: mm/-next release on web page?

From: J.H.
Date: Thu Aug 27 2009 - 18:04:21 EST

Greg KH wrote:
On Wed, Aug 26, 2009 at 05:42:31PM -0700, J.H. wrote:
Not to reply to myself, but I've pushed out an update that should incorporate the expected trees now, this does eliminate the 2.2 and all but the last 2.4 tree (, but does include all of the stable 2.6.x trees, the snapshots and linux-next. Frontpage, finger and rss should all be showing the new information universally. I'll probably tweak things a bit more (layout and such for the rss & html) but the kernels should now be listed as people expect.

This looks a lot better, thanks. But note that the 2.6.28 and 2.6.29
stable series are no longer maintained, and the current versions of them
have known security issues, so it might not be a good idea to show that
they are recommended for use at all.

Is there some way that we can "mark" activly maintained releases to have
them show up on the front page in any way? We can use the LATEST-IS
type file in the kernel directory if you want, that would be a simple
way to maintain this information.

The way the script works, in particular with regards to the ever changing realm of the 'stable' trees is this:

Wander the entire stable directory looking for git trees that have a tag that was last produced within 6 months (this can be shortened/lengthened but 6 months seemed reasonable at the time). Pull the information for those kernels out and show them. 2.6.28's last tag was 3 months ago, 2.6.29's was 7 weeks ago (almost 2 months) but things like 2.6.27 had an update 10 days ago.

I would be a bit concerned about using the LATEST-IS tags in the kernel directory, in particular there are external scripts that snag the LATEST-IS file to determine if a kernel needs to be pulled in, etc. Having multiple of those files would likely play havoc with those scripts as I'm sure they are doing something like:


It might also be particularly confusing to people to see multiple LATEST-IS'

Could do something based on the specific git tag for a tree, something like tagging the tree EOL would remove it from the list immediately, would have the advantage that should development be picked-back up and a new tag get created it would automatically show back up in the list, as well as it being explicit that that stable tree had stopped development.

For things like 2.6.28 & 2.6.29 that have more serious security vulnerabilities could setup some sort of blacklist file, or even a file that you could touch in the repo's directory that would blacklist it as well.

Like said, can always shorten the expiry period from 6 months to 3 for example which would more aggressively prune the list too.


- John 'Warthog9' Hawley
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at