As people noted in last months / years... the worlds OS, apps,
developers, and tech oriented operating system / repo / code / porters
eyeballs users and interactors have more or less moved en masse
to git, primarily on github, often augmented by running
their own git copies in house if they are a large project.
(for the record, I still run projects where I do not expect too many
external contributions in Monotone, with a public git repo explicitly
marked as «a dump of random snapshots from the real development
repositories», which makes me kind of interested in having a version
buildable without using library versions dropped because of open CVEs)
It's unlikely under what is now an ecosystem settled
into git, that any new talent or otherwise will bother
trying to use monotone or any other repo to fetch
patch hack commit etc on anyones code, regardless
of whether that code is an OS, a repo, or an app.
It's the language problem, if you are one speaking Z,
in a world where everyone else speaks only A,
you will need to adapt to them.
If monotone wants to survive in a compileable state
across OS, to maintain an example presence that
alternative repo embodiments are available that do run
and can be studied and tried out, it needs at minimum...
a) A tarball release that compiles against the latest
versions of all external libraries, and on the latest
release of FreeBSD and Linux-Debian.
Yes, this is clearly a non-negotiable requirement.
and
b) A github repo (and ticket system) that is considered an
"upstream" that can be interacted with and that will accept
maintenance patches from the OS and userspace.
There is a non-trivial chance of success with _just_ a working public
bugtracker and patches mailing list if the development is about API
compatibility fixes.
and
c) Some public FYI blurb advert when doing those interactions,
and in the topline of the toplevel README, that monotone is
accepting new maintenance / dev people. No one lives or
maintains forever, thus wise continually seek new eyballs and
people in wherever the new places are.
Indeed, someone able to make a release whenever APIs need an update is
more important than the quality of such release. (It probably doesn't
have enough changes to break stuff anyway)
Otherwise monotone dies.
If there are compilation and bug patches out there waiting to
be applied, and tarballs with them needing cut, then someone
or some group throwing a monotone continuance project up on
github and working those things there is probably not a bad idea.