Re: Is monotone dead, or is there a path forward?

[Michael Raskin]

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