[CentOS-devel] possibility of an extra-hardware-support SIG
Karanbir Singh
mail-lists at karan.org
Wed Sep 5 23:33:12 UTC 2007
Hi Phil,
Phil Schaffner wrote:
> Seems that kernels/drivers/modules diverging from the upstream would
> need to be in [a] separate repo[s], something like Johnny's 100Hz
> kernels.
I dont visualise us building complete kernels ( unless we must - and that again
is something to be taken up when we come to it ). for drivers and modules, we
should be mostly ok to stick things into extras/ however if we need to the plus/
repo is always around. Pesonally, I dont think we would need to do that though.
btw, the 100Hz kernels are called kernel-vm for this reason, so as to not
pollute and cause issues in the kernel-* namespace.
> Could get sticky, depending on license issues. Why not just maintain a
> set of links to the latest sources from the vendors?
for drivers and software ( userland stuff, or even firmware ) we should try and
make things as easy as possible, for things that we cant - yes, a best case
would be docs that make life easier, a worstcase would be a one line saying
'this vendor sux, dont use them'.
> Overall, your objectives sound great. The dark-gray territory would be
> a challenge, but seems like good CentOS value-added if done carefully,
I am sure you are around to keep us on track :)
> with appropriate caveats, and (obviously) kept outside the core repos.
> Just not sure what the advantage of a SIG is over keeping it on
> centos-devel. Please elaborate.
The idea of a SIG is to expose a target that people can hit ( vendors, users and
even other developers ). One thing we seem to lack on the centos project at this
time is focus and the idea of a target. If things need to get done, few people
are really able to isolate specific people / places / resources that they might
be able to ping.
Nothing stops us from using this list and using whatever is in place at the moment.
Also, there is a buildsystem of sorts that I use, to build driver images and
also to build kmod's for each release kernel at release + update time. And I
really would like to allow other people access to that as well. Doing so within
a smaller group might be easier than mass public access :)
Finally, it would be good to have a role that can handle all issues related to
unsupported hardware that are reported on bugs.centos.org - right now they all
get assigned to me, and inspite of the fact that I try and look at each and
every one, its not humanely possible to do and do justice to them all. Would be
nice if there was a group of people who could own and drive these issues.
Anyway, I have run it up the flagpost.
--
Karanbir Singh : http://www.karan.org/ : 2522219 at icq
More information about the CentOS-devel
mailing list