Re: Is monotone dead, or is there a path forward?
On Thu, Jun 10, 2021 at 04:41:57PM -0700, Stephen Leake wrote: > Hendrik Boom writes: > > > On Sat, Jun 05, 2021 at 08:54:25AM -0700, Stephen Leake wrote: > >> Hendrik Boom writes: > >> > >> > Or is monotone development and maintenance truly dead and I need to > >> > abandon ship and take what data I ca with me? > >> > >> Just for reference, I gave up on monotone, and exported to git. > > > > I stopped liking git when I learned about its limitations on merging and > > the need for rebasing. > > > > Of course I never really liked git in the first place. > > > > monotone got merging branches right. > > I heartily agree, but I have to use some cm tool, and maintaining enough > of monotone to keep it working was more than I could handle. I'm still pissed at Linus for essentially cloning monotone in a shitty way. Git has come a long way since then, but I still miss mtn. But I also have to work with others, and so the choice is made for me for the most part. Not an important comment, perhaps, but it's nice to see some activity on this list, and I felt the sentiment needed to be expressed. Jens -- 1.21 Jiggabytes of memory ought to be enough for anybody. signature.asc Description: PGP signature
Re: Is monotone dead, or is there a path forward?
Hendrik Boom writes: > On Sat, Jun 05, 2021 at 08:54:25AM -0700, Stephen Leake wrote: >> Hendrik Boom writes: >> >> > Or is monotone development and maintenance truly dead and I need to >> > abandon ship and take what data I ca with me? >> >> Just for reference, I gave up on monotone, and exported to git. > > I stopped liking git when I learned about its limitations on merging and > the need for rebasing. > > Of course I never really liked git in the first place. > > monotone got merging branches right. I heartily agree, but I have to use some cm tool, and maintaining enough of monotone to keep it working was more than I could handle. -- -- Stephe
Re: Is monotone dead, or is there a path forward?
>On Sat, Jun 05, 2021 at 05:51:38PM +0200, Michael Raskin wrote: >> >Is anything being done about this? >> >Is the current botan so incompatible that it's hopeless to adapt? >> > >> >Or is monotone development and maintenance truly dead and I need to >> >abandon ship and take what data I ca with me? >> >> 1. You can easily check out a branch that actually works with botan2. >> I package it for Nixpkgs and it seems to work just fine. Unfortunately >> from bootstrapping point of view, you need some monotone to check out >> botan2-compatible monotone (for packaging I exported the branch to >> GitHub) > >Very interesting. So it looks like making a proper devuan package for >monotone would require taking the old source deb, replacing the code >with your code, and updating the various dependencies in the old >manifest to new ones. Not even my code! People involved in Monotone development for a long time had already done all the actual work… just not the release. >Even without understanding much about debian packaging, that sounds >feasible. > >Where do I find the relevant monotone repositories. (I very much want >to preserve history while doing this.) Yeah, I used monotone's git-export for the same reason. I had to assign some dates to some commits where I did not pull the proper date certs (and Monotone's fast-export dummy date is before git's epoch leading to problems) mtn://code.monotone.ca?net.venge.monotone.lapo.botan2 We already had the following patch applied, so it is not incorporated in the mirror as it was not in the original branch: https://github.com/NixOS/nixpkgs/blob/92c9d7975a828bce3bc8597a83b0bd091fd1ab72/pkgs/applications/version-management/monotone/monotone-1.1-Adapt-to-changes-in-pcre-8.42.patch >Do the repositories also contain the code normally used to create deb >packages? I am no very familiar with the existing monotone code >infrastructure, nor with the processes required to submit an update to a >dropped Debian package. I think this lives separately in tags like debian-monotone-1.1-8 >And what kind of test procedures are there for vetting a monotone >release? Good question… also, good question whether this is now a forgotten arcane knowledge.
Re: Is monotone dead, or is there a path forward?
On Sun, Jun 06, 2021 at 02:18:12PM +0100, CooSoft Support wrote: > In my experience the merging in mtn presents the developer with far fewer > conflicts to resolve. Plus you can merge multiple branches in one go by > `baptising' those dev branches into the target developer/integration branch. How do you do this? > So it doesn't stand out at first, you just notice after a while that you > have a lot less work than you'd expect with other SCMs. > > As for git. Well one of the reasons that mtn is very good at merging, apart > from any algorithm that is used to do it, is that it relies on the fact that > you have a complete history and that any branch being merged must have > branched off at some point from the branch that it is being merged back > into. Otherwise you have to do a manual merge. Git doesn't place that `same > origin branch' restriction on you. There are occasional times I'd like that 'same origin branch' lifted. Mostly when I discover ancient pre-monotone source code in some archive and would like to integrate it in to monotone's history. > > Others on this mailing list may have a more in depth answer for you though. > These are just my observations. I seem to remember reading about restrictions in git on having to merge only only between very recently forked branches, and having to do rebasing to get around this. I no longer remember the details. > On 06/06/2021 13:49, Hugo Cornelis wrote: > > > > I have used monotone for a few years and was fine with it. > > > > I used to hear a lot and still hear now and then that the approach to > > merging in monotone is / was superior to the approach taken in git. It > > is something I have never understood. My experience with merges in > > monotone is actually quite limited (compared to experience with merges > > with git). > > > > How do they compare wrt merges? What is so fundamentally different > > between them? And why makes this difference such a profound impact to > > the developer experience? > > > > Just wondering. > > > > Would it be possible to integrate monotone-like merges into git? Would it be possible to integrate git repositories into monotone repositories? At the moment, traffic between monotone and git is one-way. -- hendrik
Re: Is monotone dead, or is there a path forward?
On Sun, Jun 06, 2021 at 12:53:11AM -0400, grarpamp wrote: > 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. > > 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. > > 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. > > 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. I might be willing to step up here, but I'm not a youngster that will carry maintenance into the far future. I'm 74. -- hendrik > > 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. > There used to be a very usable publicly accessible site that kept people's monotone databases online. I used it to back up my own development repositories. -- hendrik
Re: Is monotone dead, or is there a path forward?
On Sat, Jun 05, 2021 at 05:51:38PM +0200, Michael Raskin wrote: > >Is anything being done about this? > >Is the current botan so incompatible that it's hopeless to adapt? > > > >Or is monotone development and maintenance truly dead and I need to > >abandon ship and take what data I ca with me? > > 1. You can easily check out a branch that actually works with botan2. > I package it for Nixpkgs and it seems to work just fine. Unfortunately > from bootstrapping point of view, you need some monotone to check out > botan2-compatible monotone (for packaging I exported the branch to > GitHub) Very interesting. So it looks like making a proper devuan package for monotone would require taking the old source deb, replacing the code with your code, and updating the various dependencies in the old manifest to new ones. Even without understanding much about debian packaging, that sounds feasible. Where do I find the relevant monotone repositories. (I very much want to preserve history while doing this.) Do the repositories also contain the code normally used to create deb packages? I am no very familiar with the existing monotone code infrastructure, nor with the processes required to submit an update to a dropped Debian package. And what kind of test procedures are there for vetting a monotone release? > > 2. I would also appreciate an official release including these changes. So would I. I might have some time to work on it once I have the required data and permissions. (And it would help if I got monotone to work through my modem's port rerouting, but that's another thread on this mailing list) -- hendrik
Re: Is monotone dead, or is there a path forward?
In my experience the merging in mtn presents the developer with far fewer conflicts to resolve. Plus you can merge multiple branches in one go by `baptising' those dev branches into the target developer/integration branch. So it doesn't stand out at first, you just notice after a while that you have a lot less work than you'd expect with other SCMs. As for git. Well one of the reasons that mtn is very good at merging, apart from any algorithm that is used to do it, is that it relies on the fact that you have a complete history and that any branch being merged must have branched off at some point from the branch that it is being merged back into. Otherwise you have to do a manual merge. Git doesn't place that `same origin branch' restriction on you. Others on this mailing list may have a more in depth answer for you though. These are just my observations. On 06/06/2021 13:49, Hugo Cornelis wrote: I have used monotone for a few years and was fine with it. I used to hear a lot and still hear now and then that the approach to merging in monotone is / was superior to the approach taken in git. It is something I have never understood. My experience with merges in monotone is actually quite limited (compared to experience with merges with git). How do they compare wrt merges? What is so fundamentally different between them? And why makes this difference such a profound impact to the developer experience? Just wondering. Would it be possible to integrate monotone-like merges into git? On Sun, Jun 6, 2021 at 2:32 PM CooSoft Support mailto:supp...@coosoft.plus.com>> wrote: I loved using Monotone and agree that the merging in mtn is far superior to the run of the mill merging you get with git (after all it's site did refer to it as a stupid/dumb content tracker). In fact mtn's merging is the best I've ever used. I liked the fact that changesets were stored efficiently as compressed deltas in mtn as well. However the world has moved on and the projects that I work on have had to switch to git. Younger developers coming into the organisation know git but have invariably never heard of mtn. Also git does allow for history rewriting, which I know is a thorny issue to some, but the reality is that it is needed and very useful (e.g. someone accidentally checks in some creds etc). Whilst you could do this in mtn it was much more Isn't it just that the term 'history rewriting' was badly chosen? Something like 'commit refactoring' would have been more appropriate. Rewriting history sounds as being dishonest. Commit refactoring sounds like moving forward. Hugo painful. History is littered with examples of better technology losing out over more inferior (remember the video-2000/betamx/vhs debate?). Moving forward doesn't necessarily mean making progress. On 06/06/2021 10:00, Michael Raskin wrote: >> 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 >
Re: Is monotone dead, or is there a path forward?
I have used monotone for a few years and was fine with it. I used to hear a lot and still hear now and then that the approach to merging in monotone is / was superior to the approach taken in git. It is something I have never understood. My experience with merges in monotone is actually quite limited (compared to experience with merges with git). How do they compare wrt merges? What is so fundamentally different between them? And why makes this difference such a profound impact to the developer experience? Just wondering. Would it be possible to integrate monotone-like merges into git? On Sun, Jun 6, 2021 at 2:32 PM CooSoft Support wrote: > I loved using Monotone and agree that the merging in mtn is far superior > to the run of the mill merging you get with git (after all it's site did > refer to it as a stupid/dumb content tracker). In fact mtn's merging is > the best I've ever used. I liked the fact that changesets were stored > efficiently as compressed deltas in mtn as well. However the world has > moved on and the projects that I work on have had to switch to git. > Younger developers coming into the organisation know git but have > invariably never heard of mtn. Also git does allow for history > rewriting, which I know is a thorny issue to some, but the reality is > that it is needed and very useful (e.g. someone accidentally checks in > some creds etc). Whilst you could do this in mtn it was much more > Isn't it just that the term 'history rewriting' was badly chosen? Something like 'commit refactoring' would have been more appropriate. Rewriting history sounds as being dishonest. Commit refactoring sounds like moving forward. Hugo > painful. History is littered with examples of better technology losing > out over more inferior (remember the video-2000/betamx/vhs debate?). > > Moving forward doesn't necessarily mean making progress. > On 06/06/2021 10:00, Michael Raskin wrote: > >> 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. > >> > > > > > > > > > -- Hugo -- Hugo Cornelis, Ph.D. Agora Classica -- CTO http://www.agoraclassica.com/ GENESIS-3 -- lead architect http://www.genesis-sim.org/
Re: Is monotone dead, or is there a path forward?
I loved using Monotone and agree that the merging in mtn is far superior to the run of the mill merging you get with git (after all it's site did refer to it as a stupid/dumb content tracker). In fact mtn's merging is the best I've ever used. I liked the fact that changesets were stored efficiently as compressed deltas in mtn as well. However the world has moved on and the projects that I work on have had to switch to git. Younger developers coming into the organisation know git but have invariably never heard of mtn. Also git does allow for history rewriting, which I know is a thorny issue to some, but the reality is that it is needed and very useful (e.g. someone accidentally checks in some creds etc). Whilst you could do this in mtn it was much more painful. History is littered with examples of better technology losing out over more inferior (remember the video-2000/betamx/vhs debate?). Moving forward doesn't necessarily mean making progress. On 06/06/2021 10:00, Michael Raskin wrote: 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.
Re: Is monotone dead, or is there a path forward?
>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. >
Re: Is monotone dead, or is there a path forward?
There are probably some patches to apply from all these repos... https://repology.org/project/monotone/related
Re: Is monotone dead, or is there a path forward?
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. 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. 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. 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. 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.
Re: Is monotone dead, or is there a path forward?
On Sat, Jun 05, 2021 at 08:54:25AM -0700, Stephen Leake wrote: > Hendrik Boom writes: > > > Or is monotone development and maintenance truly dead and I need to > > abandon ship and take what data I ca with me? > > Just for reference, I gave up on monotone, and exported to git. I stopped liking git when I learned about its limitations on merging and the need for rebasing. Of course I never really liked git in the first place. monotone got merging branches right. -- hendrik > > -- > -- Stephe
Re: Is monotone dead, or is there a path forward?
Hendrik Boom writes: > Or is monotone development and maintenance truly dead and I need to > abandon ship and take what data I ca with me? Just for reference, I gave up on monotone, and exported to git. -- -- Stephe
Is monotone dead, or is there a path forward?
>Is anything being done about this? >Is the current botan so incompatible that it's hopeless to adapt? > >Or is monotone development and maintenance truly dead and I need to >abandon ship and take what data I ca with me? 1. You can easily check out a branch that actually works with botan2. I package it for Nixpkgs and it seems to work just fine. Unfortunately from bootstrapping point of view, you need some monotone to check out botan2-compatible monotone (for packaging I exported the branch to GitHub) 2. I would also appreciate an official release including these changes.
Is monotone dead, or is there a path forward?
On Mon, Feb 10, 2020 at 06:05:09PM +1100, Brian May wrote: > Stephen Leake writes: > > > I've just installed a new Debian 10 VM, and upgraded to testing. > > > > 'aptitude search monotone' returns nothing! > > > > Is it finally time to stop using monotone? > > monotone has been removed from Debian. As in both unstable and testing. > It only exists in old distributions. > > https://tracker.debian.org/pkg/monotone > > First it was removed from testing: > > https://tracker.debian.org/news/940070/monotone-removed-from-testing/ > > It was removed from testing because botan1.10 is no longer available in > testing. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888089 > > Then it got removed from unstable: > > https://tracker.debian.org/news/1089909/removed-11-9-from-unstable/ > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943919 > > "Please remove monotone. It's dead upstream, last upload was over three > years ago and it's removed from testing since 1.5 years." Is there any hope for monotone? It appears no longer to be in Debian stable. I'm using Devuan beowulf, which is roughly combarable to the currently stable Debian 10.0=buster. Debian buster does not have monotone. Nor, as a result, does Devuan buster. But I still have monotone available on my devian buster laptop, presumably because I had it long ago before I upgraded to the current stable system. And it still seems to work. If I were to have to re-install the OS, I would lose monotone, and hence the contents of my repositories. Is anything being done about this? Is the current botan so incompatible that it's hopeless to adapt? Or is monotone development and maintenance truly dead and I need to abandon ship and take what data I ca with me? -- hendrik
