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