OpenUru.org

I need to sync up -ou and -ou-minkata with Cyan's reference 1.912 first. I'll try to do that tonight (still unpacking ).

_R

Do we have Cyan’s reference 1.912 yet? Bitbucket and Foundry don’t look like it to me.

Anyway, I imagine it will be a while until we get the things I mentioned done (I’m uncertain whether I will get around to completing cursors until next week), so I don’t mean to put on pressure.

I have backported the JPEG fixes which were on Deledrius' list, plus one more by Zrax. I'm going to try and test these ASAP with the help of my new butler. Next, I'm going to try my hand at moul-scripts to fix the GZ glass state, and maybe a few other things I saw.
Since monthly updates seem prohibitively costly, I think we have quite a bit of time for the next update.

Any ETA on the next update for MO:ULa?

I'd also like to mention I'd like to try moving this line to after PageOutNode, which would be useful for Fun House effects to page out heavy Ages once Grey Hats are done with them. I haven't tested yet, but it looks to me like this line is the blockage.

Lyrositor wrote:Any ETA on the next update for MO:ULa?

Updates are waiting for me, I'm afraid. I need to update the binary libraries that Jenkins uses to link the client together for Minkata. The updated libraries are needed for the next updates Christian has prepared in the queue.

I had some RL items that took up a lot of time the last couple of weeks, and have been catching up on work this week. It will take me a day or so to review the items Christian has identified, make the changes, and test the build process.

If I get my current work task done tonight or tomorrow the update should happen during the weekend, and new changes can then get pushed to Minkata.

_R

Lyrositor wrote:I'd also like to mention I'd like to try moving this line to after PageOutNode, which would be useful for Fun House effects to page out heavy Ages once Grey Hats are done with them. I haven't tested yet, but it looks to me like this line is the blockage.

Please do test it if you can, then make a pull request. Before accepting something like this, I would like to see a thorough consideration of whether it has any security implications. (E.g. can you crash a client by paging out stuff? If so, can you exploit the crash for remote code execution?)

Gate crashing the technical here ...

Releasing code from this project, as close to cyans base line would mitigate the multiple build senario cutting down on cost (the donation fund).

Release management anyone ?

DarK wrote:Releasing code from this project, as close to cyans base line would mitigate the multiple build senario cutting down on cost (the donation fund).

Unless I'm missing the point of your post altogether, what I think you're suggesting here is pretty much what already happens. As for the impact of an update on the donation fund, I'd suggest not reading too much into the jump in build IDs on Cyan's client: Some of those increments happen for quite minor reasons or for things unrelated to the build of the code. In any case, the most labour-intensive part of the whole process seems to be the verification after the update has been deployed on the live server, as that pulls in pretty much the whole QA/Support team for a couple of hours.

Mac_Fife wrote:

DarK wrote:Releasing code from this project, as close to cyans base line would mitigate the multiple build senario cutting down on cost (the donation fund).

Unless I'm missing the point of your post altogether, what I think you're suggesting here is pretty much what already happens.

...

In any case, the most labour-intensive part of the whole process seems to be the verification after the update has been deployed on the live server, as that pulls in pretty much the whole QA/Support team for a couple of hours.

I'm possibly mis-communicating; Cyan’s base line/requirements for a release will include the results of QA Testing.

Could QA be done from this side with a report sent to Cyan with the relevant pulls?

If an example QA report from cyan can be obtained, a QA Release team can produce a final release document to sign the release off - this should save valuable time on cyan’s side, as they have a QA report in a format that is already acceptable to them.

In relative terms as well, Open Uru’s development is technically an Agile development cycle, where by the code is tested and released by the coders themselves. Each their own Release manager (Code, test, submit)

Dealing with many release managers at the receiving end of a tree is not a happy task, and specifically if cyan ended up with nothing past a code dump and a vague submit line, the QA would have taken more time than just a straight commit and build.

http://en.wikipedia.org/wiki/Release_management

If more work can be done on this side of the Submit to cyan – all cyan is required to do is push the button on the release once the documentation has been signed off internally, or pushed back if there is a problem.

The Minkata shard has the opportunity to extensively test everything before it goes to Cyan. No matter how much we test, Cyan will still want to do a MOULa verification. We send over a change list (Christian has been posting a change/test list to the wiki). Cyan checks against that and what they see coming across in the changesets. QA documentation? LOL. Well, I don't know of any, so we've haven't exchanged it. More time and money saved if we don't add that to the process. It is pull, commit, build and verify. So far, we haven't had to come back with a fix after verification. The fixes already happened on Minkata prior to the MOULa update. Chogon pushes the code back here to the CWE/MOULSCRIPT repos (he pulls from CWE-ou and MOULSCRIPT-ou) once the verification is complete to provide the new MOULa baseline.

Chogon wrote:And a very big special note: The OpenUru Minkata Test Shard was a tremendous help in keeping Cyan Worlds MOULa's costs down. This has 1) cut down my time/cost by only getting working changes (iterations are a time killer), 2) cut down the Cyan World's internal QA team costs in that they only have to do a verification of changes and 3) cut down server costs since we didn't have to create a beta test server. So, a big thanks! to all the people involved in the OpenUru Minkata Test Shard! Including all the testers!

http://mystonline.com/forums/viewtopic.php?p=382136

I hope this helps your concern.