| 1 |
On Fri, May 30, 2014 at 1:02 PM, Ben Kohler <bkohler@×××××.com> wrote: |
| 2 |
> As nice at it sounds to just DROP these configs, that option is not really |
| 3 |
> feasible considering the way we currently use genkernel in our handbook. |
| 4 |
> Relying on the kernel's own defconfig, "genkernel all" will NOT produce the |
| 5 |
> same mostly-usable-on-any-hardware result that we now rely on. |
| 6 |
|
| 7 |
Considering that the configs are more generically useful than |
| 8 |
genkernel, having them separately maintained sort-of makes sense. |
| 9 |
Then genkernel is a kernel build/install/initramfs tool, not a config |
| 10 |
management tool. |
| 11 |
|
| 12 |
I'd stick them someplace where any dev can get to them, and separate |
| 13 |
them from the genkernel functional code base. |
| 14 |
|
| 15 |
As far as who takes care of them goes - I suggest that this stuff |
| 16 |
comes out of the devmanual unless somebody steps up to take care of |
| 17 |
them. Those who take care of them become those who want to keep them |
| 18 |
around. You can't toss out a tool and ask for it to be a |
| 19 |
recommendation but point to others that you think need to maintain its |
| 20 |
configuration. |
| 21 |
|
| 22 |
Rich |
Archives