Wanted: new maintainer

[aqw]

This project is in need of an active maintainer. Please express if you're interested in working through some of the open PRs, issues, and/or getting a final 2.0 release out.

[lestercheung]

What needs to be done to push v2 out? The master branch is usable for years (use it everyday - thank @aqw !) - just want to see v2 make it into debian/ubuntu archive 😄

[aqw]

@lestercheung That's a good question.

My ancient todo says:

todo:
  2.0.0:
    testing:
      test for local
    documentation:
      multiple prefixes supplied in one call
        e.g. -p 'hourly- daily- weekly-'
      periodic files
    make output similar to ZFS style: would vs will
      be verbose on failure, don't be silent
      double verbosity will output actual ZFS commands
    periodic scripts, test
    handle pools/fs/snapshots with with spaces in them: fuck
      add tests for all TrimTo* and Valid*
      IFS can't have <space>
        Can it be default? Child shells don't always inherit I read
            bad idea, people will source core.sh, and we don't want to mess with IFS silently
        set it, unset it?
      building lists, don't use space
      make sure quoting passes through to actual ZFS commands, destroy, snapshot, recurseback, etc
      test for all allowed ZFS special characters
    use depth to limit destroy's snapshot list creation
    generate new html
    rename SkipPool, would be an API change
    rename ValidSnapshot to IsZFSNAPSnapshot
    use semi-colons where appropriate, rather than &&

But that's not to say that any of those are actual blockers.

My brain tells me that the concerns I had were:

• IFS issues with datasets with spaces in the name (especially dangerous when playing with "destroy"
• the language ("would" and "will")
• following the above to: concern about whether zfsnap should follow, or break severely, with upstream's syntax. I have never been a fan that zfs destroy -rv dataset deletes without prompting. One must add -n to no-op it. zfsnap inherits this design decision; and I think it should be chnaged to: no-op by default; prompt to delete; add -y to force yes. However, that would be a huge break in expectation for users of zfsnap.
• improving the tests further (arguably not a blocker, but always wanted when playing with data)

IMO, these are all decisions for the maintainer. If you're interested in working on this, and making measured decisions that respects users, then I say go for it. :-)

[graudeejs]

@awq I propose we archive this repository. Do you agree?

[aqw]

@graudeejs Sadly, I agree.

Thanks for having created this software. It's been fun to use and to hack on. I just havn't had the time for a long while now.

[mmatuska]

I am busy with other stuff, too. libarchive
But I guess we could release version 2.0 - OpenZFS did this yesterday.

[graudeejs]

I don't believe we should release anything, it's unmaintained. Whoever wants to use it can fork or use latest commit.
Or someone can find my contact info (on my homepage) and take over and move on.

[graudeejs]

Peter Preeper has been granted write access to repos as he's willing to become maintainer.

Good luck @ppreeper!