Repository. Mercurial still good?

[ajmas]

I am in the process of looking to create a Linux based VM running MOSS and I am wondering whether the project is still using Mercurial for the source?

What I have seen:

- https://foundry.openuru.org/hg/MOSS -> seems okay
- https://bitbucket.org/OpenUru_org/moss -> offline, due to Bitbucket dropping Mercurial
- https://github.com/openuruunofficial/MOSS -> a little out of date, but using Git

Also, being used to front-ends like Gitlab and GitHub, I spent some time trying to work out how to browse the repositories to get the code. Would this be the best place to go, rather than Fisheye and Crucible: https://foundry.openuru.org/hg/ ?

[JWPlatt]

Mercurial support has been dropped in favor of Git as the dominate force today.

Use these Git repos:
https://foundry.openuru.org/gitblit/repositories/

They are actually a mirror of our BitBucket repos. BitBucket recently dropped Mercurial, which is why we did too.

The Development page of our site naviagtion is out of date and needs to be updated.

[ajmas]

Any objections if I update the Wiki?

BTW would it be worth adding a README.md to each project, describing the project and setup details?

[rarified]

Any objections if I update the Wiki?

BTW would it be worth adding a README.md to each project, describing the project and setup details?

Hi ajamas! It's good to see new interest in the OU repositories.

JWPlatt is correct, the current repository is on the Foundry server. Work to mirror it with BitBucket is in progress, but is a lower priority than some other work, and took a complete back seat to getting the first fan content through the pipeline to MOULa.

With regards to MOSS, even the Git repository is way behind the "current" source being used on Minkata, the only shard that I know of that uses MOSS. I alone have been nursing it along, and will have to work to organize the changes in the current build workspace into a series of separate commits to the MOSS repository corresponding to fixes I've implemented over the years. They cover everything from bit-endian fixes that arose running MOSS on Solaris with older Posix/XPG standard environment, to fixes handling SDL for new ages, and a lot of instrumentation.

What timeline are you looking to meet with your project? I'm working with other developers to document the changes that were required to build the CWE client code under Visual Studio 2010 (there already is documentation here but it is now incomplete due to additions that were made to the client to once again play video). Similarly build instructions for the other projects are available on the OpenUru wiki. Eventually those could be condensed into per-project README.md files, but things are too fluid right now to have to maintain multiple sets of instructions. So I would advise against creating README files at the moment.

Let me know how you want to proceed. I could make the raw source from Minkata's version of MOSS available in a ZIP file for now, but I would request no parts of it be checked in before I get a chance to - as I said above - split the changes into appropriate functional commits to go into the repository.

_R

[ajmas]

I am not working with any specific timeline. I got here by means of an e-mail to the Cyan mailing list. I then started exploring and getting lost, since it feels a lot hasn't been refreshed in a while.

The goal for trying to create a VM (probably via an Ubuntu based Vagrant deploy) is multiple:

- validate the documentation
- see how the documentation can be improved
- make it easier for anyone to deploy
- using Linux, rather than my host OS (macOS), provides a more accessible reference platform

BTW is there any reason not to use GitHub as a source mirror, given its visibility?

WRT to the Visual Studio dependency, this would be mainly for the client, rather than the server?

[rarified]

...

BTW is there any reason not to use GitHub as a source mirror, given its visibility?

We started a relationship with Atlassian a long time ago, with their contributing licenses for their tracking software to OpenUru, and our using BitBucket as our public mirror. At that time our repositories were entirely based on Mercurial, and BitBucket was the primary public open source repository available.

While we did have an unpleasant experience when BitBucket capitulated to the public migration to Git as "the" SCM to use, and BB deprecated their support for Mercurial repositories, I still have all the metadata extracted from BitBucket regarding pull requests, issues, and commits that I should be able to re-apply to the Git versions of our existing repositories. I'd like to keep that history intact, and for now I think that is most easily accomplished staying with the BitBucket platform.

I also think there is some benefit in spreading out public instances of repositories related to our projects. The H'uru team uses GitHub for their public repository base. Should either GitHub or BitBucket change policies or otherwise become untenable to use, the other repositories remain available.

WRT to the Visual Studio dependency, this would be mainly for the client, rather than the server?

Correct. MOSS originally was written on FreeBSD as it's host OS, and some people have used it on Linux. Minkata on my server runs on Solaris.

_R

[ajmas]

On the subject of H'uru, what is the relationship. It is a fork or the next iteration of OpenUru?

[rarified]

It is both... Shortly after Cyan released the client as open source, there was disagreement with a group of developers that had a lot of experience with the Uru client (from reverse engineering) about the scope of some changes they wanted to make to the code base. That group (H'uru) decided to fork the Cyan code and proceed at their own pace and their own direction, while OpenUru held back and worked to keep our code compatible with what was felt Cyan would accept for MOULa.

Small extracted improvements were migrated from the H'uru base to OpenUru (and to MOULa), but the process of keeping up with those transliterations became too unwieldy to continue and OpenUru's base (and MOULa) fell "behind" the extent of the changes present on the H'uru base.

Most active developers right now work from the H'uru base.

I remain the most significant developer on the OpenUru side. Having worked to extract as much from H'uru as was necessary to accommodate Fan ages, and with Cyan having relaxed their needs and then designating the fan community as the owner of the client code, I have on my plate the task of synchronizing the bulk of H'uru back into the OpenUru source base, and then releasing it to Cyan to install on MOULa. (OpenUru still plays a role as the testing and validation step, and the final build step, before passing the client to Cyan for MOULa). That is the big project for this winter.

_R

[rarified]

BTW ajmas, I sense some interest on your part about involvement with development on all sides of the MOUL ecosystem.

There is plenty of work on the OU side that would benefit from another developer. Do you know if something piques your interest that you could contribute here?

_R

[ajmas]

There is interest on my side, but I have a number of other commitments so I don't want to be promising anything or diving in too fast.

What I am seeing at the moment is a development environment that has a lot of hallmarks of 2012 and are probably in need of modernising. The hope here is that by bringing in things up to date and making it easier for people it would help contributions - though seeing the number of abandoned projects on GitHub I appreciate this is no guarantee. If I am being too harsh, do tell me - I admit I haven't opened the cover of this book too far.