Hi Fabian,

I think some of this might be getting into specifics - my aim was just to really see if there is any interest level in this kind of work. However, all the issues raised are important so lets discuss them at this stage.

Fabian Arrotin wrote:

...

• Find and coordinate the efforts by various hardware vendors to support CentOS

If the HW manufacturer lists RHEL as supported, the driver/module they provide should be supported on CentOS as well ... Do you mean that these manufacturers list CentOS itself as supported ?

That would be a good thing, if we can get ( like we did with 3ware ) to list CentOS as being supported directly, it increases the confidence level of users with that specific hardware. Also, that would give us the potential to push for centosplus kernel support as well ( which is almost non existent at the moment ).

...

• Create, test and publish a mechanism to follow kernel updates ( might need

someone to actually have access to some of this hardware, but it should be manageable specially if we can get the attention of hardware vendors ).

in kmod format i suppose ?

if we need to, yes - otherwise start with the dd.img and follow with weak-updates. You dont always need to update drivers with a new kernel version on centos :)

actually, to be completely honest, I dont care - if people prefer dkms or kmdl, we should have support for those as well. Setting up an automated system to hammer these out is trivial. I already have something functional, with a bit of clean up that can be made into a generic setup we can all use and a process that can be audited by vendors is also easy to implement. This takes away the amount of work they need to do themselves, lowers the bar of entry and actually increases the consistency of the drivers out there.

I think it's a good idea and i can join the effort ...

excellent!

For example i have to setup IBM SANs and the multipath driver is delivered as source (which is a good thing on one hand) but who has make and gcc on a server ? ... :o)

is this driver gpl / open source ?

This make me think to the license point of view : can every driver/module be packaged ? This has to be taken in account ...

If people are putting out drivers that are not open source friendly, then we can only do some docs on making it easier for users to use them. beyond that there is little that can be done.

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.

Hi,

I dont quite understand the context of this or how it might apply to us. We are not looking to start off dozens of projects, and if we were - there are enough resources going around to handle stuff of this nature inhouse.

gjgowey@tmo.blackberry.net wrote:

Just a couple thoughts from the sidelines.

always welcome :)

If there needs to be a forum for development of a particular item of interest then why not have the founder of the idea start a sourceforge project to get the ball rolling? This way the idea can go from conception to being worked on using the ideas of its founder without tying up or waiting for resources reserved for more mainline projects. To keep the ball rolling give the core members of centos full access privileges so that the project never risks becoming orphaned. Starting a wiki on the centos main site to post and discuss these splinter projects might also be a good idea as it could serve as a master link list of sorts for these projects instead of relying on word of mouth or searching through mailing list archives.

there is a wiki at http://wiki.centos.org/ - so any project or work that we are doing will get mention there and on the website. I dont understand how mailing lits on sf.net would be different from mailing lists here. Btw, these are not splinter projects - this is work we hope to do, to be directly usable on the centos distro. I would consider it more of ValueAdd rather than a splinter. IMHO keeping such things inhouse and under one roof also means lesser work for people who are involved with multiple issues like this. Which is something we all are really.

The advantage of the above system is that it would allow the splinter projects to do as they please without worrying about the affects on mainline resources during their alpha and beta stages (which would be a problem if the code of such projects were housed under the plus repository). Once the project has matured sufficiently then it can be evaluated for inclusion in the plus repo. It also has the advantage of allowing such splinter projects to be as active or as idle as they want without them being forgotten (courtesy of the wiki) or orphaned (courtesy of sharing full control with the core centos members).

We have both testing and staging / playpen / sandbox setups within the centos infrastructure, and going by the logs - they get used quite a bit.

With regards to your unsupported drivers problem, it might be worth making a small program that generates a web page to just display open issues (one row per issue). This way people can see what's out there to be fixed (and maybe a splinter project can form to work on it).

ok, this one completely eludes me :) a one line of what do you want displayed ? If you mean just list drivers that need working on, why cant we use bugs.centos.org ? it seems to be a perfectly usable issue tracker.

On Thu, 2007-09-06 at 12:06 +0000, gjgowey@tmo.blackberry.net wrote:

On Thu, 2007-09-06 at 12:44 +0100, Karanbir Singh wrote:

...

there is a wiki at http://wiki.centos.org/ - so any project or work that we are doing will get mention there and on the website. I dont understand how mailing lits on sf.net would be different from mailing lists here. Btw, these are not splinter projects - this is work we hope to do, to be directly usable on the centos distro. I would consider it more of ValueAdd rather than a splinter. IMHO keeping such things inhouse and under one roof also means lesser work for people who are involved with multiple issues like this. Which is something we all are really.

It's basically aimed at letting individual developers start projects that they feel would benefit centos do so basically on their own terms and let those projects be run using sourceforge resources until they're sufficiently mature enough to be integrated into the mainsteam centos development path. The provision of allowing core centos members joint full control over these independent projects is so that the incubation period can be as long as need be without risking the project becoming orphaned.

Please avoid top-posting. If I am correctly interpreting the context of your reply, it is reconstructed above.

This effort does not seem appropriate for SF, although it could involve packaging hardware drivers available there for CentOS. SF hardware projects seem to be targeted at supporting particular hardware, not providing drivers for a variety of hardware for a particular OS (but, I admittedly have not studied the 100,000 SF projects, nor even the 700+ in the hardware drivers category). I think, as Karanbir apparently does, that trying to host it there would tend to splinter the CentOS-centric effort.

Phil -- to-borrow-a-sig --

A: Because it messes up the order in which people normally read text. Q: Why is top-posting a bad thing?

gjgowey@tmo.blackberry.net wrote:

It's basically aimed at letting individual developers start projects that they feel would benefit centos do so basically on their own terms and let those projects be run using sourceforge resources until they're sufficiently mature enough to be integrated into the mainsteam centos development path. The provision of allowing core centos members joint full control over these independent projects is so that the incubation period can be as long as need be without risking the project becoming orphaned.

if people are interested in creating sub-projects or creating/starting code work that might be of some use to the CentOS userbase, we have resources within the project that people would be most welcome to ask for.

If someone has something in mind, please feel free to ask. We can provide pretty much anything that someone might want, any sort of VCS, mailing lists, trac instances, bugzilla instances, webhosting space and a very effective mirror network.

as much as possible, it would be nice to not spread out too thin, however if people would still like to use the likes of sf.net to host a project - I would really like to know why. Perhaps, we could use that feedback to do things better.

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