[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