On Thu, 2007-09-06 at 00:33 +0100, Karanbir Singh wrote:
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.
Agree. Just meant it as an example of separate repo outside the current CentOS structure, not to imply that new kernels were necessary for this purpose; although would not exclude that if it proved expedient.
btw, the 100Hz kernels are called kernel-vm for this reason, so as to not pollute and cause issues in the kernel-* namespace.
Hummm - doesn't seem to be the case on my VMware CentOS-5 VM:
[root@c5 ~]# rpm -q kernel kernel-2.6.18-8.1.8.el5 kernel-2.6.18-8.1.8.SMP.100HZ.el5
But I digress.
If other non-standard kernels were provided, a kernel-xyz naming convention might be a good a good policy.
[ Continuing digression: Would also address the issues I have encountered with the current naming convention where yum considers kernel-2.6.18-8.1.8.el5 to be later than kernel-2.6.18-8.1.8.SMP.100HZ.el5.
http://bugs.centos.org/view.php?id=2189 ]
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 :)
You are too kind, sir. May need a lawyer for that purpose. :-P
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.
OK - understood. Was just afraid of "splintering" or fragmenting the resource pool if the effort were too separate from core CentOS. Sounds like we are on the same page there from the above and another reply in this thread.
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 :)
Mass public access to your buildsystem would certainly not make the job easier. A common buildsystem for these add-on drivers would probably be a requirement for the release versions.
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.
Understand that you could use help. OTOH, my experience is that if an issue or action-item does not have a single stuckee, it does not get done. If ownership of a particular issue were adopted by a member of the "Value-Added Driver SIG" that should work.
Would seem these drivers would be of value to others (i.e. EL, SL) as well.
Anyway, I have run it up the flagpost.
Seems at least a few are saluting. :-)
Will help where I can, but don't have a wide variety of hardware running CentOS available, nor a lot of time to volunteer. My "day job" is research on airborne sensors for aviation safety and CentOS is just one tool in the toolbox.
Phil