>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. >