Re: mm/-next release on kernel.org web page?

["J.H." <warthog9@kernel.org>]

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