suspend/hibernate on desktops

Thorsten Leemhuis fedora at leemhuis.info
Mon Jan 16 08:41:35 UTC 2006


Am Montag, den 16.01.2006, 13:49 +0530 schrieb Rahul Sundaram:
> >Just my 2 cent here: No. The real fix it to get the work done upstream
> >and fix remaining parts in our main kernel (if we have to). 
> >  
> >
> Yes of course but allowing kernels helps get wider testing.  Same as 
> Fedora-netdev http://people.redhat.com/linville/kernels/fedora-netdev/ 
> or regular updates to FC4 updates-testing repository planned out by Dave 
> Jones.

Sure. And, btw, I really like the work they are doing. But that testing
and work helps the kernel in general.

Working on swsusp2 is probably a dead end (sometimes I hope I'm wrong on
this, but I don't think I am). But now that a lot of work is done on the
mainline kernel swsusp is seems even more unlikely to me that swsusp2 or
parts of it gets merged.

> >Putting a kernel in extras is a bad idea in general IMHO. We then
> >probably would have to build kernel modules for them, too. And other
> >people probably would start submitting other Kernels (with the realtime
> >patches for example). This would probably end soon in a great
> >unsupportable mess with a small benefit. "Upstream" really is the best
> >solution. 
> >
> I agree in general but if the community wants to maintain such kernels 
> why should we stop them?.

In the swsusp2 case: Because it takes away testers and users aways from
our core kernels (and the work that is done by upstream, too). And we
want a swsusp to work there out of the box in the longer term.

Ingos Realtime work might be something different. Parts of it might not
make it to the kernel, but probably some will. But maintaining such a
beast is quite a lot of work and IMHO should be done outside of Fedora
Extras. But maybe I'm wrong.

What do others think?

>  The Extras repository has no guidelines 
> against allowing parallel installations of packages. If kernel's are a 
> exception they should be written policy with good rationale. 

Let's see what comes out of this discussion. Maybe we should write a
policy depending on the results. 

CU
thl




More information about the fedora-devel-list mailing list