Is vcsh Dead? Or, "For Whom the Bell Tolls; It Tolls for vcsh."
leycec opened this issue · 6 comments
As the unresolved pile of pending issues and pull requests begins to fester in ever-increasing coils of putrid bit rot, that perennial Github question rears its gangrenous face:
"Is this repository dead?"
Yes. Yes, It Probably Is.
For all practical intents and purposes, vcsh is dead.
The last commit to the master branch, seemingly the last commit to any branch, is nearly a year old. Pull requests remain unmerged or even commented upon. Issues remain unresolved or even commented upon. The litany of community woes grows wider, deeper, and more desperate by the mythical man-month.
Should we care?
Yes. Yes, We Probably Should.
If you're reading this, you probably leverage vcsh for that most sacred and holy of digital tasks: dotfile synchronization. You may even open-source those dotfiles as public Github repositories, complete with a vcsh one-liner simplifying installation for both yourself and anonymous others. Aren't you awesome?
Like me, you're unwittingly invested in the future safety and security of vcsh. When vcsh was well-maintained, this investment reaped ample dividends. Life at the command line was never better! Today, only the bitter ashes of those better days remain.
vcsh is no longer well-maintained... or even maintained at all. If left to die alone in the snowbank, vcsh could genuinely become unusable or at least less usable on modern systems at some unspecified future date. All it would take is a single unforeseen deprecation of a single command-line API that vcsh depends upon by a single upstream git, shell, or distro maintainer.
Bam! Thus ended vcsh – not with a shebang, but a Github whimper.
vcsh Deserves Better
What can we as the vcsh community due to remedy this trail of dead? In no particular order:
- @RichiH could anoint one or more trusted contributors with commit access. This is probably the ideal response. For all the usual reasons (namely, trustworthiness in a room of slit-eyed knife-fighting delinquents), this also seems like the least likely response. I can only pray and beg for an enlightened decision. 🙏
- One or more committed developers could officially fork
vcshinto a new project. For uniqueness and hype generation purposes, a new name is advisable.vcshng?vacuush?evacush? I don't know. Why should I? It's your new project. I'm sure you'll think of something.
I myself lack the time, money, blood, tears, and/or sanity to either assist in the continued development of vcsh itself or maintain a proper vcsh fork. Nonetheless, I wish whoever does well on their profound journey into Bourne shell madness.
You are the hero that vcsh deserves.
Hi,
yes, it deserves better. There's too much backlog and too little time. This was, and still is, one my "for 2017" things and thankfully that's near.
Still, this wakeup call was in order.
I would love to give access to a few people, but I never found someone who had 100% the same vision; maybe that's unrealistic, maybe this call could help.
The main time sink with PRs and issues is to try and figure out how they work really well with the Grand Vision and with the code that's, potentially, to come. That's also my main concern from experience: making sure things do not break.
What would really really help is an expanded test suite that ensures changes don't break anything. The current one is fragile and does not cover nearly everything. Any help there would be highly appreciated.
I suggest another course of action: Call it done.
No one seems to be overly motivated to take over development of vcsh and it probably works perfectly for 99% of its users. So, @RichiH, perhaps it is time to say no to any new features and only commit to making bug fixes as they arise and your time permits? I think there is no shame in that. If someone motivated does show up, that person can always develop further in a fork.
As to vcsh's completeness, I'm actually still using version 1.20131229.git-HEAD which I reviewed and then stuck in my main dotfiles repo around that date. I'm probably missing some nice features (and so I've been considering updating) but even several years ago, vcsh worked great. With vcsh I've been happily avoiding the unmanageable situation of my $HOME itself being a git repo without some symlink mess. Thank you, @RichiH for this great software which is nearly as indispensable to me as the shell itself.
Also, as someone who has written and maintained a lot of Bash code, my personal feeling is that once you hit a certain point in complexity for a professional piece of software, it really ought to be rewritten in a proper programming language. Something that has strict error checking, concise syntax, one compiler/interpreter, less surprising behavior, etc. It would probably even come with a test framework or at least have something well accepted for that language. But that's just my opinion if I had a grand vision for some software like this. :)
I've actually been doing a bunch of incremental refactoring over at https://github.com/djpohly/vcsh/tree/refactor... creating functions, cutting down on global variables, and the like, trying to make the codebase more manageable. Not adding features or fixing bugs yet (though I'm keeping a list of what I see), so the functionality should be exactly the same. I've also got some tests allowing me to make sure I haven't too severely broken anything; more are of course welcome.
I think the thing that keeps me from cleaning up more deeply is that I don't know how every piece of vcsh is intended to work... for instance, is $VCSH_COMMAND supposed to be visible to the running command itself, or is it meant to be internal? What is the envisioned use case for each of the various hooks? Etc. @RichiH, if you are open to occasional questions of intent and "vision," I'd be willing to run with this for a little bit.
Meantime, if anyone out there wants to test my refactored branch on their setup, I'd appreciate extra confirmation that the behavior is identical. :)
