> It doesn't have a homepage
Sure.
> the source code is not hosted anywhere
We have more than a few formulae grabbing source tarballs from the Debian repository. This could fall into the hosted by Debian category if you like.
> the project has not been continued or taken over by anyone else.
As I said, it doesn't have to be taken over by anyone. This is open source code on the open web, freely distributable by anyone.
> We fall short of almost all of our own criteria.
Acceptable formulae criteria are mostly enforced at the time of *accepting* formulae. IMO retroactive enforcement *for the sake of enforcement* is misguided.
> This increase maintenance burden for little use, if we try to be a software conservation project.
The formula is not broken. If it's broken I'm all for throwing it out. But it's not.
Thanks.
> show the full path of the conf.py used so it will be easier to see and fix it by the user as you already did on your project settings.
Yeah that would be very helpful.
May I ask if there's more reason than "it is unmaintained since 2011"? It builds fine here, and Bintray statistics show quite a few downloads (330 over 30 days): https://bintray.com/homebrew/bottles/xml2#statistics.
To be clear, I don't use this formula myself, but it's worrisome to me that "X is unmaintained since 20XX" is used as the sole reason to trash a considerable number of formulae that might be working just fine (possibly indefinitely into the future). Many battle-hardened old Unix utilities can be called "unmaintained" — in many cases you can't find an upstream; you may find individual distros do a bit of downstream patching (or not at all), and that's it. These utilities may be bug-free enough that they don't really need maintenance. A concrete example is Vixie Cron. It went unmaintained in the 90s (or 2004 if you count ISC Cron). Apple's port hasn't been touched since OS X 10.8, which you can confirm on opensource.apple.com. Yet to this day I use it literally every single minute.
In this specific case, the package is [carried by Debian](https://packages.debian.org/jessie/xml2), it still works (excuse me if I'm wrong), and people still use it, so I don't see why it should be trashed.
> The counter-argument I'd put forward is that the ffmpeg project supports multiple minor versions, and while there isn't a @3.1 or @3.0 in homebrew-core at the moment, someone may need to add one at a later date. Also, a future @3.x may be more breaking than expected, so there would be a need to differentiate between 3.x and 3.2, which would require renaming too.
For end users using the `ffmpeg` family of command line tools, there's little to no reason to use a legacy branch of FFmpeg. For developers using the `libav*` family of libraries, as far as I know it's been relatively painless to port code from 2 to 3 (in the grand scheme of things), let alone from 3.x to 3.x+1. Some projects also vendor `libav*`. IMO adding unnecessary complexity for the sake of one of the countless things that *may* happen in the future is a pit we all fall into way too often.
Disclosure: @ilovezfs might know that I've never been a big fan of versions in core, so I'm apparently biased towards fewer versions.