OpenUru.org

Tracking how the source code for CyanWorlds.com Engine and MOSS is something we can't and don't do with our use of Mercurial for source management. Once a clone is made from the OpenUru repositories, we have no knowledge of where the clone is, and if there is a project behind it's use that would be of interest to the community.

I would like to extend an invitation to the people who have obtained a clone of the repositories on OpenUru.org to append a post in this thread if you are using the clone to work on projects that might be of interest to other members of the community, or if you're interested in soliciting the participation of the community on your project. If you have a website or public repository server, leave a link. If you're willing to be contacted by others about your project, put some contact information in the post.

I'd like to keep nudging folks to share as much information about their goals, accomplishments, and progress as possible. The more we know about each others efforts, the better we can coordinate those efforts and explore the possibilities that have opened up.

Thanks
_R

There's a git repository at http://github.com/H-uru/Plasma. So far we've got most of the build converted to CMake, and along with that most of the #include statements have been fixed to use saner include paths. This was made as a direct conversion from a clone of the mercurial repository, and can be easily converted back to mercurial to be merged with OU when and if it's decided that the CMake build system is wanted here. It's probably not going to be long-term compatible with Cyan's codebase.

I also have a clone at http://bitbucket.org/branan/cwe that just contains Zrax's VS 2008/2010 code fixes. This should be immediately compatible with the current tree, and can probably even be pushed to cwe-compat as a potential thing to share with Cyan.

I have put a clone at https://bitbucket.org/cwalther/cwe to publish my cursor improvements. Depending on how the contribution process on OpenUru.org evolves, it may or may not stay there and be used for more contributions in the future.

Do you want our Fisheye/Crucible to track changes to it, and handle any reviews or workflow related to it? Also do you want a JIRA project for your work?

_R

That depends on where these changesets propagate… I’m hoping that they will soon appear somewhere on the OpenUru.org foundry, where they are tracked by the foundry tools anyway, in which case tracking my Bitbucket repository would be unnecessary.

I consider my use of Bitbucket for this a temporary choice until a contribution workflow is in place on OpenUru.org. (It may of course turn into a permanent one if that workflow turns out to involve Bitbucket.)

I don’t think a new JIRA project is needed, this is part of the CWE project.

Ok. Just FYI the changesets can exist in an off-Foundry repository and the repository tools can be configured to monitor them as well.

Let us know when you want a Foundry repo for any of this stuff. Or if you'd just like to merge it into an OpenUru branch of the CWE repository.

_R

Let's just prep the CWE repo for our plan to open it to developer (non-default, non-ou) branches and get Christian going. We'll still need to work more on the review and test process, but we'll be on our way. Any objections? Make a backup.

There's also a VS project file fix waiting in the wings that could get pushed.

I started a new Wiki page "Using the OpenUru Repository" I need to flesh out first to describe the use of branch names and why users should avoid referencing the "tip" version from now on. If that info is not out there, we're going to have a lot of confused users!

_R

JWPlatt wrote:Let's just prep the CWE repo for our plan to open it to developer (non-default, non-ou) branches and get Christian going. We'll still need to work more on the review and test process, but we'll be on our way. Any objections? Make a backup.

There's also a VS project file fix waiting in the wings that could get pushed.

Oh, is that the project file fix I just pushed?

Oh, well. It seemed to belong in the default branch because 1) it fixes what is broken 2) it is not incompatible with MOULa. I guess if I did it wrong you'll move it around.

Anyway, no objections to branches from me. I could have used a -dev branch to review said fix, too.

One comment. We need a clear explanation of what -default, -ou, and whatever mean. And maybe a branch picture. Oh. What rarified just wrote.

- a'moaca'