lkml.org 
[lkml]   [2009]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2009-08-28 00:07    [W:0.233 / U:0.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site