Hi Akemi,

On Jan 12, 2011, at 17:31 , Akemi Yagi wrote:

> On Wed, Dec 22, 2010 at 12:10 PM, Akemi Yagi <[log in to unmask]> wrote:
>> On Wed, Dec 22, 2010 at 10:34 AM, Stephan Wiesand
>> <[log in to unmask]> wrote:
>>> 
>>> Since I have very limited experience with these kmods, it would be really great to hear from the elrepo folks whether/why the above changes are stupid. Alan, Akemi, Dag, ..., are you reading?
>> 
>> We are reading  :-)  But we have not been following up quite well :-(
>> We would be happy to discuss with you as soon as we digest the
>> details.
> 
> Hi Stephan,
> 
> Jack Neely wrote to the elrepo-devel list and offered to contribute
> the openafs packages to ELRepo.  So, most likely, he is going to be
> the maintainer for ELRepo.
> 
> We have yet to publish the packages from the srpms Jack submitted, but
> are you going to maintain yours for SL? Or you'd rather join us?
> Whichever the case, I think we can help each other.


certainly, and I'd welcome any cooperation on the openafs packaging.

However, we should also cooperate with - and probably: in the context of - the upstream project, openafs.org. They have been providing RPMs for RHL/Fedora/RHEL for a long time. It's an open source project, well managed, with open and archived mailing lists for users and developers, very responsive and helpful maintainers, a very responsive and helpful community, and - for a while now - with a public git repository and a means to submit changes to an open review process on gerrit.openafs.org. And they are open for contributions. In fact, they ask for them every time in presentations in the US and European workshops twice a year. And they've made it easy to contribute. All it takes to submit a change for review (or to contribute to the review of others' changes) is an OpenID and some minor setup work on your side.

This makes OpenAFS very different from, say, the nvidia driver. And probably most (all?) of the other ELRepo packages. For those, there is no upstream open source project already building packages and inviting contributions.

For this reason, IMHO, it's not expedient to create yet another set of openafs packages. There's a real chance to get the openafs.org packages into a state where there's no need for another packaging at least on EL6.

In fact, as I said in the message opening this thread, my personal main objective regarding the SL packages is to make them redundant :-) By bringing the SL and openafs.org packaging closer together, from both ends. There's a number of obstacles to making them completely identical, and there's a small number of very serious ones, but I think we should see how close we can come. And the closer, the better for everyone - especially those using them. I've started working on this, but it's going to take its time.

Regarding SL, it's really up to Connie and Troy whether SL6 will ship its own openafs packages, and which ones. I just offered what I have to the project. If they pick something else, fine. If those packages (or the openafs.org rpms, or the elrepo ones, or the rpm fusion ones, or the atrpms ones, or...) work for the systems I support, I'll drop mine immediately. Where "they work" at least means: there's a way to have working modules for *any* kernel installed on the system, not just the latest one, using nothing but yum or rpm. To the best of my understanding, this rules out the current ELRepo packages if/when the ABI used by the openafs modules changes, which can happen. Feedback on this issue, and the way I tackled it by making minute changes to the packaging, is still very welcome.

Regards,
	Stephan


-- 
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany