Information gathering to assist overview planning

[DarK]

I understand that the code is just over two weeks out of the box now, and I am looking to step forward to take on some basic tasks to learn the code and in time get back into programming again after a bit of a hiatus.

I think I can do this by taking on the Project Lead (or at least assisting someone else if they think they would be better up to the task), by putting forward some organisational skills which will allow others more talented to jump in and start coding, without a steep learning curve.

I’ve been doing some reading on progress and I am concerned about documentation and the lack of any particular break down of how or what each entity is working on and what the final goal is, so I would like to set a discussion up on those points,

As an example there are issues surrounding SDK redistribution for PhysX and OpenAL –is this been worked on, has there been any discussion on this – if so where?!

This will be helpful so I can start to use the tools (JIRA etc) and start to build a picture of current development, this will enable coders to communicate efficiently on the issues they are tackling – and help other people participate more.

I’m keen to de-personalise the leadership roles, I want to listen to technical people and hear their points, no matter how big or how small, technical or not, Based on this feedback I can start to build an overview for people to use as a base for project plans, and assist in establishing development process.

If you can take 2 minutes to post in this thread, or post a link to another thread, a bug on a tracker, information on where best to lurk in IRC, anything that would help me gather information on what is relevant and is been worked on currently, what needs to be worked on, and anything that has been suggested already on implementations for technical or procedural requirements would be massively helpful.

With this information I can start to place down issues in JIRA to help build the bigger picture, which in turn assists bringing people in to help claim these issues from JIRA and tick them off as completed.

I want to make clear that I don’t want to rule what you work on or how you work on it, I just want to know what you are working on, and any information you think is relevant - so that there is some clarity on the direction that is been taken.

No matter what your development I would like to know about it.

[Mac_Fife]

All offers of help are welcome! Especially as a few folk here are busy catching up on some of the "day job" work we should have been doing while we were getting the Open Source release ready instead.

As an example there are issues surrounding SDK redistribution for PhysX and OpenAL –is this been worked on, has there been any discussion on this – if so where?!

Picking up on that particular point, the position on the licensing and redistribution of the SDKs themselves is pretty much covered in the wiki (CWE Libraries and SDKs), but I think you're really referring to the question of redistribution as part of a compiled and linked binary. Here, the issue is one of the implication of using these SDKs with source code that is ostensibly under GPL3. That is a question that has been pursued with the Free Software Foundation and the conclusions are with Cyan for consideration. That is an email exchange so it doesn't appear here in any form (yet).

[JWPlatt]

Welcome back, DarK. Your interest is much appreciated.

I'm going to leave a general note for now, but I am prepping an outline of how we're proposing to structure the repositories - just one aspect of operations and process.

We have been coming up with a more solid repo structure. This will lay out the purpose/goal of CWE. We'll have a treatment on this for the wiki as soon as possible. What we haven't completely nailed down yet is the review and merge process - something a manager would be very interested in making clear. Some of the trouble is performance-related with Crucible. That needs to get settled and, yep, managed.

In the forum and wiki docs you may have also seen my outline for various lead positions. Yes, we're waiting for qualified people who are respected by the community at large to take initiative and let us know what they can do. We're here to provide resource support, but we can't do it all. We need motivated people, including people who are motivated to motivate us. But most people are naturally just those who want to play the game and want new features.

We need someone to scout or take pull requests and get them into the repo for testing and review. Though I would think a manager would enjoy overseeing their own team with that. This needs to be effectively built into our structure so it can be fairly autonomous, but managed. We're all doing this for free, so we don't want to have something so intensive it takes all our time and risks burnout. We want people to stick around.

We're here to explain things about the resources we provide. And the more explaining we do, the more others see the activity and begin to learn. It really helps to motivate us when people contribute and want to get something done. Thanks!

Builds are a big capability of the Foundry. We're a bit stuck by licensing with some SDKs, but how builds will work, how people will get to them, and documentation would be a big head start, even if things are just placeholders for now.

We'd like to make it easy and desirable to do work here. That means cooperation, taking pull requests, as I mentioned, using all the open source work made available to the community, and making sure talented people get all the credit for the good things they do. Something like that would be really effective in making it a community effort. If a manager could pull that off, it would be doing a great service for everyone. All it takes is to make things attractive and easy for all developers.

[Nye_Sigismund]

[...] I’ve been doing some reading on progress and I am concerned about documentation and the lack of any particular break down of how or what each entity is working on and what the final goal is [...]

Might as well punch in here with a quick bit of info on the GoW programmer's current work and aims, as much as I'm aware of them.

The GoW decided to fork the code pretty early on after OU put out the CWE tree. They ported the code to CMake, made it compile in newer and free-er ( ) versions of Visual Studio, got the Max plugin ported mostly over to newer versions of Max... and a few other things.

I'm not really sure of the goal of that fork long term. The GoW will break compatibility with Cyan content at some point, probably when they seek to change CWE to run on an open-source physics engine like Bullet.

There does need to be an expressed final goal, I suppose. That's complicated, especially because you have two camps:

a) Improve Uru.
b) Improve the CWE (so not Uru-centric).

The final goal for my development (which is content) is "Make MOULa into the best possible realisation of the Uru concept, where best possible is defined as most fun."

Given that the name of this website is, in full, Open Source Uru, though, I think that OU-centric development is probably best fitted towards a) rather than just b). CWE can develop in all kinds of directions, but I prefer the path of keeping fairly close to the MOULa format, seeking to build a pipeline which suits all parties, of which one, but only one, is Cyan.

[rarified]

Hi DarK, welcome to the circus

As Ian and JW have already said, help is welcome in any and all forms. I am the caretaker of the Foundry, and have been trying to make time to start a bit of the documentation you were looking for but couldn't find. Real life demands have taken some of the steam out of those plans, but they still need doing.

We launched Open Source with a pretty generic set of tools, with the expectation of tuning them as well as starting to explore - on-the-fly - various processes and flows people would follow to contribute. It does seem likely we'll have to implement at least a first try at defining those processes ourselves to let people move forward with their individual projects who may not be as interested in a larger project management perspective.

To start, we experimented with a repository organization that had a separate staging repository for contributors to commit their work into, and then (assuming the contribution was changes to something we already have, rather than a totally new and independent project) look for willing and qualified people to act as an informal review board to examine the changes, and provide feedback. If between the developer and reviewer agreement happens and both agree it's ready to join the communal pot, the changes would be pushed (by myself in one case, or by one of the reviewers) from the staging repository to the master repository. We currently have access controls in place on the master repository that only individuals that have been involved in reviews can make the final push.

Since a couple of changes have come in (from various sources, including Cyan) it is becoming more apparent that in the master repository we'll want to have several concurrent variations on projects be stored. In SCM parlance, that would be implemented as "branches", which are simply labels attached to all changesets (groups of changes put to the repo as a single transaction) that are associated with a particular variation of the project stored in that repository. Asking the SCM to retrieve a branch, say it's called "moula", might bring back all the source code in the same condition as that used to build and run the current MOULa servers and clients (assuming Cyan has been able to provide us with those versions). Another branch might be the "openuru" branch, where we might have some things Cyan hasn't integrated into MOULa for whatever reason.

Since we are heading toward a branch-based repository structure, it makes little sense to keep a staging repository for developer submissions when the same thing could be accomplished with a "development" branch. We can apply different access rights to individuals on a per-branch as well as per-repository basis, so the "development" branch could be wide open for submissions, while the "openuru" branch is only writable by proven contributors and reviewers. This is where I see us heading next.

Unfortunately, what I just wrote above is a small chunk of the documentation newcomers will need to be able to effectively use the repositories and get the results they expect. Branching makes it more tricky to get the files you expect, and you have to be careful when committing changes to the repository to make sure it's associated with the branch you want. Using the default settings on the tools will no longer be sufficient.

The repository conventions and instructions are but one part of the whole environment. We have as you have discovered JIRA and Fisheye, which can be coupled with the repositories very closely so commentary from bug reports and reviews are easily associated with particular pieces of code.

At the other side, the Foundry is set up to perform what is called Continuous Integration, meaning that the process of translating code to programs, assembling the programs into something that can be made available for download (perhaps in the form of installers), and also running tests (when and if they are available), all can be performed automatically based on triggering events such as a new change appearing in the repository. That work has yet to really take off; I've confirmed the virtual machines I have as part of the foundry can build the CWE and MOSS code when done by hand, but I need to configure the CI system to do the same thing automatically.

Right now I don't have specific technical changes I plan to make to the Uru ensemble, but I do want to start working to machine generate documentation from the existing source code with Doxygen. That will provide web-browsable abstractions of the code class structure and interfaces, and after the automatic part is working we can start adding commentary to the code that is displayed by Doxygen in the documentation to try to make it easier to understand how things work for those of us (me!) unfamiliar with the code. Then I might feel qualified to pick out things in the code to change!

Ok, this is longer than I expected, but hopefully gives you an idea of my involvement and what I am proposing as things that need doing. At some point in the future, I may also seek others to help with the operation of the Foundry, but that's a pretty big learning curve to climb.

_Rarified

[Nye_Sigismund]

Sweet lord, wall of text!

I think that sorting out the repo stuff is important - the OU toolset's powerful but it's obvious that it needs some hammering. One thing that's needed is a simple way to monitor development amongst all branches, like how I've seen it done with Git.

In any case - so basically, the repo might be organised like this:

MOULa - the MOULa code as it currently is.
OpenUru - Good things done in Dev go here. The "stable" development branch?
Dev - The open development branch, which most people will branch from and commit to. The "unstable" branch?

Seems like a nice workflow. I personally am interested in larger project management stuff, so hopefully I'll be of some use down the line to somebody. :\

[DarK]

Wow! Good Stuff

I will start processing this and getting issues into JIRA - please feel free to correct anything along the way, or take up the ticket and update it with progress if you are dealing with the issue already.

I realise how the repo structure will alter things once it has been finalised, but I want to map and document the repo discussions as a test bed to see the best way to use JIRA for management purposes. I can then work on migrating the issues to the new structure and suggest more changes as required.

This should happen over the next few days.

Is it possible to get hold of editor or a more privileged status on the JIRA for my user to allow me to mess around a bit more with the structure?!

[rarified]

Is it possible to get hold of editor or a more privileged status on the JIRA for my user to allow me to mess around a bit more with the structure?!

Yes, although it's granted on a per-project basis. Do you want to try things in a disposable test project, or think it's appropriate to experiment on one of the main branches? I'd want to check with a project owner if you wished higher privileges on personal projects.

_R

[JWPlatt]

This thread is about planning so I'm not going to clutter it up with techical details. I would just like to provide a link to a new discussion about the "Repository Structure" for your reference as it does have an effect on planning and management.

viewtopic.php?f=91&t=562

[rarified]

One thing that's needed is a simple way to monitor development amongst all branches, like how I've seen it done with Git.

Nye,

Could you elaborate on this point some more? Receive commit notifications? Something else? Let me know.

Thanks
_R