Fasd: add a maintainer?

I'd be willing to help a bit with the maintenance.

I sent @clvv an email. Let's see if he responds.

If nothing comes from that, perhaps @PythonNut or @josephholsten could set up an org independently?

It's kind of hard to tell what's going on because there's been so many forks. I think infokiller/fasd may be the one that has diverged the most from this version.

@marlonrichert, @clvv has been inactive since 2016 (hope he's still alive), so probably you'll never get a response back from him.

As for the GitHub org, I'm not sure if it makes sense to create a whole org just for one simple repo. Maybe it's better to just create a new fork and add collaborators to it.

It's kind of hard to tell what's going on because there's been so many forks. I think infokiller/fasd may be the one that has diverged the most from this version.

@infokiller, would you be willing to make your fork the "official" one or set up a new GitHub org for fasd?

@clvv has been inactive since 2016 (hope he's still alive), so probably you'll never get a response back from him.

He's alive and well and published a cryptography paper in 2019: https://wdai.us

I'm happy to make my fork official or set up an org. My fork is indeed maintained, and I made some improvements, like bugfixes, shellcheck compliance, new options, better debugging (this was a big paint point), and other stuff I probably don't remember. I also have code in my dotfiles that integrates it with fzf, which I believe is better than the built in matching it had (faster, more accurate, more flexible, more maintainable, etc.), and I can add it to this repo.

That said, there's cons in me doing this:

• I only tested my previous changes in bash 4+ and zsh. I probably need to clean up the code to handle some bash 4+ features (the original code is supposed to be POSIX compliant). I'm willing to do it if it's not much work, but if it will make maintenance much harder I will probably lose interest in the project.
• I don't use MacOS, so I can't test that configuration.

@infokiller I'm using fzf-tab plugin, so it replaces the default zsh TAB behaviour to always use fzf. Do you think your fasd fork will present incompatibility with it?

I'm willing to do it if it's not much work, but if it will make maintenance much harder I will probably lose interest in the project.

I think that alone already presents a good argument for making it an org.

@FreddieOliveira no it shouldn't cause any issues: it only defines functions that integrate them, and completion will be opt-in
But also note that the fzf changes are not in the fork right now (they're in my dotfiles repo).

Ok, I've grown tired of waiting, so I created an org @shell-fishes and added you all to it as owners. It's the worst possible name I could come up with, so please consider coming up with a less terrible name.

If you would like to set the scope for the org as wider than just maintaining fasd, that would be cool too. I have created two orgs like this in the past: @sous-chefs & @terra-farm. They have patterns about codes of conduct &c that we could adopt, or not. Discussion about the org can go in https://github.com/shell-fishes/meta/issues

OK, nice initiative! I accepted the invitation. Now we should decide which version/fork of fasd will be our initial base.

It's good to see continued interest on this project. I apologize for ghosting this project for so long.

I really have no intention of making any further changes to fasd. It is by all intents and purposes a completed project. I personally view it (and use it) similar to things like cd, grep or sed. You don't want to find out your grep is behaving differently because of some new update.

I have always been using my local copy of fasd, and that is probably what I would recommend for anyone using fasd. In retrospect, I should not have submitted this to any package managers. And at the current stage (I know there are bugs, and probably some terrible vulnerabilities), it really shouldn't be offered on any package manager and should only be used at users' own discretion.

That being said, I think the best path forward is to have community-based forks. I will update the README to indicate the inactive status of this repository, as well as giving pointers to forks.

@clvv I think the biggest question is: do you mind us using the name fasd, or should we change it for our fork?

By your analogy to cd, grep or sed, it sounds like you're supporting differing and incompatible implementations that share the same command name. But I know we all want to respect your work and don't want to confuse users.

@infokiller could you hit up @whjvenyl and see if we could get him involved as well?
Been using his fork for ages, and can see you've pulled some changes from there as well.

Sure they're welcome to join and I'll compare the forks