[elrepo] el6 kmod-ocfs2 & ocfs2-tools packages

[Dag Wieers]

On Mon, 11 Apr 2011, Mikey Austin wrote:

>> This new situation has some new characteristics:
>>
>>   - more work to produce
>>
>>   - no real releases like we were used to before
>>
>>   - no clear upstream source to track (mainline ? oracle ?)
>
> Do you think it is reasonable to conjure up our own release numbers for
> the kmod-ocfs2 el6 packages if we, say, created the RPMs from mainline
> (given upstream don't use version numbers in mainline [1])?

The versions from mainline have a higher risk to (at some point) break 
with RHEL's kernel. For that reason I would recommend we start from 
Oracle's own (2.6.32 ?) kernel if that is at all possible.

I know I mentioned using mainling from the post you provided, but I have 
changed my mind. I'd rather ship something Oracle signed off on and that 
integrates better with the 2.6.32 kernel. Do you agree ?


>> But then there's the question about workload, and tracking new releases,
>> and the new complexity. And we would need people to test those releases as
>> well because we have no setup to test new releases.
>
> Tracking new releases is the biggest unknown in my mind. As for the
> testing, I could set up some VMs in my company's dev network to test out
> the el6 packages.

That would be very useful.


>> If the new strategy by Oracle is not putting you off, maybe you can help
>> us with the kmod-ocfs2 RPM packages in the future ? It's always useful to
>> have someone in the field leading such an effort.
>>
>> Would you be willing to help ?
>
> I am very willing to help in any way that I can.

Ok, let's look for the ocfs2 code from UEK first. Then integrate it in a 
new set of modules for RHEL6 and see where we end up.

-- 
-- dag wieers, dag at wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info at dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]