[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Additional kernel options and devices



Hi!

On Tue, 2011-02-08 at 18:55:25 +0100, Petr Salinger wrote:
> >If you and other are of the view that the BTS is the best
> >first step, then I will abide that mechanism of raising any
> >issues concerning the capacity of the packaged kernel.
> 
> The mails into BTS are forwarded to maintainer e-mail
> (which is debian-bsd@lists.debian.org).
> 
> So discussion takes place on this list and is stored in BTS.

Right, but I think a wiki page with the summary and the rationale for
the specific options would be easier to handle, than having to crawl
the bug report or the list archive.

> >When writing "central information source" I loosely imagined
> >some sight at Alioth or wiki.d.o display or mentioning in what
> >sense kFreeBSD is advancing ahead of FreeBSD proper regarding
> >default device support. (Sorry for the lengthy explanation.)
> 
> In wiki, there might be summary of changes (like enabled quota),
> but detailed reasoning would be stored in BTS (and list archive).
> 
> We might also alter our kernel config files into:
> -----------------
[...]
> ---------------------------------------
> 
> This way would be clearer our difference against upstream GENERIC.

That'd work fine for uncontroversial changes, or things that are known
not to possibly break the rest of the kernel functionality. I guess
the question here is to what extent we want to diverge from upstream
default options? And on which cases, given that upstream might not
have enabled them because they are not deemed ready for wider use,
for stability, performance, or other reasons.

A possible solution to this could be to build another kernel image
flavour with some default diverging options enabled, and once and if
they have been tested successfully we could consider moving specific
ones to the main images.

regards,
guillem


Reply to: