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.