Messages in this thread | | | Date | Thu, 27 Aug 2009 15:03:14 -0700 | From | "J.H." <> | Subject | Re: mm/-next release on kernel.org web page? |
| |
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 (2.4.37.5), 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:
ncftpget ftp://ftp.kernel.org/pub/linux/kernel/v2.6/LATEST-IS-*
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.
Thoughts?
- John 'Warthog9' Hawley
| |