It appears there is significant interest in working with EFS in my new role, but not necessarily for what you would expect. We're working on a basic framework for SAN and NAS administration, and we're very interested in reviving the old NetApp code, and implementing something new as a framework for managing SAN storage. We are also *starting* our Linux environment with NFSv4 using krb5, and won't be using NFSv3 at all, so we'll finally get that support (which will, BTW, mean being able to drop the requirement that efsd run as root).
Now, I obviously still have commit access (let's face it -- 95% (probably more) of the code changes in git belong to wpmoore anyway), and I've signed the contributor agreement, but let me know how you guys want to handle the process going forward. Realistically, I was always the "gatekeeper" for changes that were merged with the master branch, and for what constituted EFS 3. Since I've seen virtually nothing done to EFS since I left my previous role, and since I have been told the old team is focused on issues with EFS 2, we need to make sure we're on the same proverbial page about how things in EFS 3 will move forward. I can happily maintain my own branches for the functionality I need, but I will be implementing things in a generic, configurable fashion, and everything will be intended for inclusion in the main master branch. Let me know what you guys think about this.
_______________________________________________ EFS-dev mailing list [email protected] http://mailman.openefs.org/mailman/listinfo/efs-dev
