public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-dev] Too many kernels?
@ 2004-07-09 23:22 Grant Goodyear
  2004-07-09 23:32 ` Greg KH
  2004-07-09 23:35 ` Kumba
  0 siblings, 2 replies; 8+ messages in thread
From: Grant Goodyear @ 2004-07-09 23:22 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 607 bytes --]

# ls /usr/portage/sys-kernel -l | grep -v CVS | wc -l
44

Anybody know which kernels are actually being used?  Which have active
maintainers?  Given the goal of a quick response to kernel
vulnerabilities, it seems clear that each kernel needs a redundancy of
two to three people who can update handle patches when the need arises.
(That doesn't mean we need 3*44 kernel devs; a high degree of
overlapping would be fine.)

-g2boojum-
-- 
Grant Goodyear	
Gentoo Developer
g2boojum@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [gentoo-dev] Too many kernels?
  2004-07-09 23:22 [gentoo-dev] Too many kernels? Grant Goodyear
@ 2004-07-09 23:32 ` Greg KH
  2004-07-09 23:57   ` Mike Frysinger
                     ` (2 more replies)
  2004-07-09 23:35 ` Kumba
  1 sibling, 3 replies; 8+ messages in thread
From: Greg KH @ 2004-07-09 23:32 UTC (permalink / raw
  To: gentoo-dev

On Fri, Jul 09, 2004 at 07:22:51PM -0400, Grant Goodyear wrote:
> # ls /usr/portage/sys-kernel -l | grep -v CVS | wc -l
> 44
> 
> Anybody know which kernels are actually being used?  Which have active
> maintainers?  Given the goal of a quick response to kernel
> vulnerabilities, it seems clear that each kernel needs a redundancy of
> two to three people who can update handle patches when the need arises.
> (That doesn't mean we need 3*44 kernel devs; a high degree of
> overlapping would be fine.)

I am trying to slowly weed through all of these, and delete the ones
that are no longer needed (I did 2 last week.)

Note that a lot of these are either:
	- arch specific
	- patchset specific

The arch specific ones should have maintainers, the arch maintainers.
The patchset specific ones are (in my opinion) pretty much pointless.
Sure, some people like them, but it seems like a strange way to track a
-mm or -aa or -ck kernel using a ebuild.  But that's just my opinion.

Oh, remember, those patchset specific kernels usually never get the
security updates that the "supported" kernels do (g-s and g-d-s).

thanks,

greg k-h

--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [gentoo-dev] Too many kernels?
  2004-07-09 23:22 [gentoo-dev] Too many kernels? Grant Goodyear
  2004-07-09 23:32 ` Greg KH
@ 2004-07-09 23:35 ` Kumba
  1 sibling, 0 replies; 8+ messages in thread
From: Kumba @ 2004-07-09 23:35 UTC (permalink / raw
  To: gentoo-dev

Grant Goodyear wrote:

> # ls /usr/portage/sys-kernel -l | grep -v CVS | wc -l
> 44
> 
> Anybody know which kernels are actually being used?  Which have active
> maintainers?  Given the goal of a quick response to kernel
> vulnerabilities, it seems clear that each kernel needs a redundancy of
> two to three people who can update handle patches when the need arises.
> (That doesn't mean we need 3*44 kernel devs; a high degree of
> overlapping would be fine.)

I'm probably going to dump mips-prepatch-sources (which is an empty 
directory anyways), as I've decided that maintaining -rc, -pre or -bk 
ebuilds becomes too much of a hassle as they move too quickly.


--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond

--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [gentoo-dev] Too many kernels?
  2004-07-09 23:32 ` Greg KH
@ 2004-07-09 23:57   ` Mike Frysinger
  2004-07-10 11:01     ` Michael Kohl
  2004-07-10  1:25   ` Terje Kvernes
  2004-07-12 20:45   ` Aron Griffis
  2 siblings, 1 reply; 8+ messages in thread
From: Mike Frysinger @ 2004-07-09 23:57 UTC (permalink / raw
  To: gentoo-dev

On Friday 09 July 2004 07:32 pm, Greg KH wrote:
> The patchset specific ones are (in my opinion) pretty much pointless.
> Sure, some people like them, but it seems like a strange way to track a
> -mm or -aa or -ck kernel using a ebuild.  But that's just my opinion.

i think tracking patchsets which can be found via kernel.org is ok ... makes 
life easy to not have to d/l the linux tarball and patchsets yourself all the 
time ...
-mike

--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [gentoo-dev] Too many kernels?
  2004-07-09 23:32 ` Greg KH
  2004-07-09 23:57   ` Mike Frysinger
@ 2004-07-10  1:25   ` Terje Kvernes
  2004-07-10  1:28     ` Greg KH
  2004-07-12 20:45   ` Aron Griffis
  2 siblings, 1 reply; 8+ messages in thread
From: Terje Kvernes @ 2004-07-10  1:25 UTC (permalink / raw
  To: Greg KH; +Cc: gentoo-dev

Greg KH <gregkh@gentoo.org> writes:

  [ ... ]

> The arch specific ones should have maintainers, the arch
> maintainers.  The patchset specific ones are (in my opinion) pretty
> much pointless.  Sure, some people like them, but it seems like a
> strange way to track a -mm or -aa or -ck kernel using a ebuild.  But
> that's just my opinion.

  personally, I find it very practical to have emerge fetch and patch
  the patchset-kernels I use -- I run -mm and occasionally test -ck.
  this makes it one less thing I have to think about looking for every
  so often, even though I get l-k delivered.  ;-)
 
> Oh, remember, those patchset specific kernels usually never get the
> security updates that the "supported" kernels do (g-s and g-d-s).

  "security" is rarely the reason for using patchset-kernels.  for my
  part, it's mostly to test the newest and greatest sources with a lot
  of extras.  considering FireWire, SATA and a few other tidbits like
  that are used a lot around here, I tend to test tings quite a bit.
  and for the record, I really wish my motherboard had something other
  than Sil3112.  SATA compliance with as much fuzz as possible.

  
  but, since I'm curious...  Greg, are you maintaining g-d-s these
  days?  if so, I could move a box or two over.  SATA shouldn't be a
  problem there, should it?  :-)

  oh, and how you find the time to do all that l-k work and Gentoo is
  damn impressive.  thank you for all the time you give to us users!
 
-- 
Terje - who wants to try the hotswap SATA canisters on his server.

--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [gentoo-dev] Too many kernels?
  2004-07-10  1:25   ` Terje Kvernes
@ 2004-07-10  1:28     ` Greg KH
  0 siblings, 0 replies; 8+ messages in thread
From: Greg KH @ 2004-07-10  1:28 UTC (permalink / raw
  To: Terje Kvernes; +Cc: gentoo-dev

On Sat, Jul 10, 2004 at 03:25:14AM +0200, Terje Kvernes wrote:
>   but, since I'm curious...  Greg, are you maintaining g-d-s these
>   days?

Yes I primarily am (with help from others at times.)

> SATA shouldn't be a problem there, should it?  :-)

Works for me :)

> Terje - who wants to try the hotswap SATA canisters on his server.

Hm, I don't know if we have hotplug SATA support in the kernel just yet.

thanks,

greg k-h

--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [gentoo-dev] Too many kernels?
  2004-07-09 23:57   ` Mike Frysinger
@ 2004-07-10 11:01     ` Michael Kohl
  0 siblings, 0 replies; 8+ messages in thread
From: Michael Kohl @ 2004-07-10 11:01 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 753 bytes --]

On Fri, 9 Jul 2004 19:57:44 -0400
Mike Frysinger <vapier@gentoo.org> wrote:

> i think tracking patchsets which can be found via kernel.org is ok ...
> makes life easy to not have to d/l the linux tarball and patchsets
> yourself all the time ...

FWIW: How about using ketchup for this? It should also save you some
bandwith as it only downloads patches, a feature kernel ebuilds don't
give you.

http://kerneltrap.org/node/view/2976
http://www.selenic.com/ketchup/ketchup-0.7

And I also want to thank Greg for maintaining g-d-s, it's nice to have a
competent person looking after my favourite kernel sources. :)

Regards,
Michael

-- 
www.cargal.org 
GnuPG-key-ID: 0x90CA09E3
Jabber-ID: citizen428 [at] cargal [dot] org
Registered Linux User #278726

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [gentoo-dev] Too many kernels?
  2004-07-09 23:32 ` Greg KH
  2004-07-09 23:57   ` Mike Frysinger
  2004-07-10  1:25   ` Terje Kvernes
@ 2004-07-12 20:45   ` Aron Griffis
  2 siblings, 0 replies; 8+ messages in thread
From: Aron Griffis @ 2004-07-12 20:45 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 563 bytes --]

Greg KH wrote:	[Fri Jul 09 2004, 07:32:25PM EDT]
> I am trying to slowly weed through all of these, and delete the ones
> that are no longer needed (I did 2 last week.)
> 
> Note that a lot of these are either:
> 	- arch specific
> 	- patchset specific

I'd like to switch to g-s and g-d-s for ia64 if possible, but I would
need you to add on the ia64 patches from

    http://www.kernel.org/pub/linux/kernel/ports/ia64/v2.4/
    http://www.kernel.org/pub/linux/kernel/ports/ia64/v2.6/

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2004-07-12 20:54 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-07-09 23:22 [gentoo-dev] Too many kernels? Grant Goodyear
2004-07-09 23:32 ` Greg KH
2004-07-09 23:57   ` Mike Frysinger
2004-07-10 11:01     ` Michael Kohl
2004-07-10  1:25   ` Terje Kvernes
2004-07-10  1:28     ` Greg KH
2004-07-12 20:45   ` Aron Griffis
2004-07-09 23:35 ` Kumba

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox