Maintenance Status of this repository

[igalic]

Hi folks o/~

I would like to inquire as to the official maintenance status of this library.

• There are several issues open on this very repository
• there's an "official" fork at freenas/py-libzfs
• packages are cut from that fork
• the package vanished from the HardenedBSD repo: py-libzfs HardenedBSD package not available bsdci/libioc#178

This entire situation makes contributing to this project — heck, even just deciding whether you're going to use it extremely confusing.

[gronke]

I agree to what @igalic is saying. This library is joyful to use, but working with it requires occasional pull-requests. I'm willing to contribute towards feature detection and help establishing a test, build and deploy process, so that other projects may (constantly) rely on it.

[kmoore134]

@jceel We'd be more than happy to take back maintainership of this repo. Speaking for iX / FreeNAS, we of course have a vested interest in keeping this current and are willing to shoulder that burden if you are unable to work on it anymore.

[jceel]

Thanks, but no. I will happily accept any help in establishing deployment machinery and test framework though, as well as regular pull requests. @kmoore134, the best way for you to contribute is to submit pull requests. I'm reviewing them as they come along.

[gronke]

I'm glad to hear that @kmoore134 :) Seems our best option is to create pull-requests for the work that the FreeNAS fork is ahead and to work on a continuous deployment over here. @jceel has an awesome track record on GitHub and I have full trust in him holding the keys.

Can we all agree that automated deployment deployment and a strategy to deal with future interface changes* is sufficient to make our projects happy?

*) We should always test building on CURRENT, so that we're no longer surprised by libzfs changes.

[kmoore134]

@jceel With all due respect, this repo looks more or less dead, whereas all ongoing work is happening upstream at iX. Considering this code was all originally developed under iX contract, is there any way we can peacefully try to get this moved back to its original upstream? We already have various CI infrastructure in place, and plan on doing more with respect to this and other repos we depend on for HEAD / STABLE.

[gronke]

We already have various CI infrastructure in place

I was looking for a deployment tool that is capable to test *BSD system software (because we need that to get automated unit tests for libiocage), but didn't find anything suitable. One of the main reasons to build a library for iocage was to integrate it into build runners. I'd love to hear about existing solutions that can do the job! (Being able to run unit tests is a huge deal for the project)

[igalic]

opening libzfs up to linux would be one "simple" possibility, as it would mean we could test on Travis-CI.

---

none of the comments so far address the fact that the package is cut from freenas/py-libzfs (or the fact that the package vanished from HardenedBSD's repository)

What i am seeing however, is that there's obviously bad blood.

As a contributor this just sends me reeling back 🙅
and, as a user, i'm now scrambling 😱 trying to decide if i made a really bad decision building my infra on this library.

[jceel]

There was a fork of py-libzfs running with ZoL, so it's easily portable (ZoL, like FreeBSD employs a similar opensolaris compat layer). I can make it work with ZoL and then we should be good with running Travis CI. Even though py-libzfs was developed on FreeBSD, it's by no means FreeBSD specific.

So, out of all the areas needing improvement, I think the most important one is lack of the docs - even in the simplest form, as docstrings, and a user's guide. I'll handle that one and create Sphinx docs project that gets automatically pushed to GitHub pages.

In terms of future plans, I think one of the ways to go forward with py-libzfs, py-bsd, py-cam, py-netif, py-pf, py-krb5 and py-nv is to form a "Python FreeBSD toolkit" hosted under FreeBSD's github account or in SVN and maintained by the FreeBSD community as a whole. One of the most important issues with all these libraries is that we have to chase ABI changes in FreeBSD or ZFS all the time - putting the responsibility for these at the same people who make said ABI changes would streamline the whole process (which currenly is: "oh noes, it stopped working at r345678, we gotta chase what has changed and why to fix it").

BTW: I know that py-libzfs is the hottest stuff out there, but please check out and give some love to the other BSD-related libraries next time you're about to make a gross shell call from your script! (: