View source for Arianne Development Meeting 2016-01-06

We will meet in #arianne on irc.freenode.net, https://webchat.freenode.net/?channels=arianne on Wednesday, 6th January, 2016 at 20.00 server time (19.00 GMT)

== Sourceforge, Github, Travis ==

In August after an extended downtime of Sourceforge, we created the Arianne organisation on Github and mirrored the Stendhal git repository. Back than the mirroring was only from Sourceforge to github, and it was done by the testserver build script once a night.

Since then we have improved the situation significantly: The mirroring is now done in both directions, and it is done almost instantaneously. This means it does not matter anymore whether commits are done to Sourceforge or Github. So we can use Github features such as pull request. And we can make use of Travis for running the JUnit test. [[Two way git mirror]] explains the details.

In addition to Stendhal, Marauroa is now on github, too. 

All JUnit tests for Marauroa [https://travis-ci.org/arianne/marauroa] and Stendhal [https://travis-ci.org/arianne/stendhal] are passing. So before we do a new release, we can just check there. In addition, Travis will execute the test suite for each pull request and post the result directly to the pull request page. Unfortunetelly there is nice output of failed tests. So in case of failures, we have to look at the console log or execute the tests locally. 

Failed tests are reported to IRC again. We should add the [https://travis-ci.org/arianne/stendhal.svg build-passing image] and Github to [https://arianne-project.org https://arianne-project.org] and [[Stendhal Testing]].

We should document pull requests on [[How To Create Patch For Stendhal]]. We can recommend pull requests, but accept patches as well. For those familiar with Github pull requests are easy. But patches are simpler for the others.


== Prepaing release of Marauroa 4.0 ==

A couple of years ago we started to experiment with web clients. We did several attempts using different technologies. To cut a long story short: Only recent browser developments enabled us to build a working webclient. All this time, most of Marauroa's development was done on a branch named perception_json, with only minor changes being backported to master.

Without a real working client, I was afraid that the Marauroa interface were not tested against real requirement. But the last attempt to write a Stendhal webclient is very promissing (although there is still a lot of work required). So perception_json branch was merged into master recently.

We should do a Marauroa release in the near future: Release bockers are tagged with [https://sourceforge.net/p/arianne/developers/search/?q=labels:%22MARAUROA_03_99%22 MARAUROA_03_99]

* Most important is updating documentation and examples.
* Stendhal should be able load the maps from transfer-content so that that part of the json protocol gets tested as well. Currently Stendhal uses Marauroa's binary serialization internally to provide content. So either the JavaScript needs to understand it, or the server needs to provide alternative content
* Changing structure of gameEvents table to use references instead of source string. Postponed after 4.0
* Re-adding support for Marven which was deleted because mvn test is broken and Travis insists on using Maven instead of Ant. We should aim to restore it before release. But this is not a release blocker.

== Doing Sendhal releases ==

* At the moment I am the only person who can do a Stendhal release. If I am not available and there is an active contributor, lots of changes pill up. This is hard to review, and I assume it may be frustrating for contributors. Creating a release, however, is both complicated and time consuming.
* ...
<!--
21:16hendrik3. Stendhal releases.
21:17hendrikI am concerned about Stendhal releases, and my role in them.
21:18hendrikIn the past, we had releases a lot more often. I mean it is okay not to do a release, if there are no changes.
21:18hendrikBut during the last year, there have been lots of changes by AntumDeluge and soniccuz. And still no timely releases.
21:19hendrikAnd I am the bottleneck here. Doing a release is a lot of work. So if I don't have time, there is no release.
21:20hendrikIn addition to the work of just doing the release, more changes mean more things to test, more time needed. And so a negative feedback look is created.
21:20hendrikloop*
21:23hendrikI like the way AntumDeluge maintained https://stendhalgame.org/wiki/Stendhal_Testing
21:24hendrikSo that it is easy to search, which changes have already been tested.
21:24hendrikto see*
21:24markusyes, that was really a good thing. :)
21:25hendrikPerhaps, I should go into more details, on how a release is created:
21:26hendrikThere are basically 5 phases.
21:26hendrikPhase 0: Preparing the release
21:27hendrik* discuss when to have the next release
21:27hendrik* test all changes and the standard tests for every release
21:27hendrik* remind about CHANGES.txt
21:27hendrik* gather screenshots and think about announcement text.
21:27hendrik* created git branch
21:28hendrikPhase 1: Building and testing of release files
21:29hendrik* this step needs admin permissions
21:29hendrik* checkout the release branch on the build system
21:29hendrik* build the files and updater
21:30hendrik* upload the updater files to the staging area
21:30hendrik* test the updater by using server.update-prop-0.95=http://arianne.sourceforge.net/stendhal/updates/update-0.95.properties.xxx
21:30hendrikPhase 2 and 3: Doing the release for real
21:30hendrik* this is the point of no return
21:31hendrik* upload all files to the correct places
21:31hendrik* update the websites, take the announcement live
21:31hendrik* update the stendhal server and enable the updater
21:31hendrik* restart the server
21:31hendrik* this step needs admin permissions, too.
21:31hendrikPhase 4: After release
21:31hendrik* spread the word
21:32hendrik* update twitter, facebook, sourcefroge news, arianne-announce
21:32hendrik* libregamewiki, gaming.wikia, ...
21:32hendrik-------
21:33hendrikI hope I did not bore you to death.
21:33hendrikSteps 1-3 are a very brief summery, the is a detailed document with all the commands.
21:34hendrikDo you have ideas on how we can get releases more often?
21:37markusAt a first glance: do not put the whole burden on one person. I'll help whenever I can, but I also have not too much time. (might become better in the future)
21:40hendrikPhase 0 and 4 could be put on more shoulders easily, I think.
21:41kiheruI don't have any other ideas. Some of the work is harder to share than others. I can try to help where I can
21:41hendrikthank you.
21:41balaurMaybe it would also help if as many of these steps were automated (create branch, make build, upload, ...). Or are they already?
21:42hendrikOnly a very little. But you are right, it makes sense to put some more effort into automation here.
21:43hendrikSome things are complicated to automate, but it is probably worth to do it anyway.
21:44balaurThe detailed document... is it on the wiki?
21:45hendrikIt is in the admin section, so not really.
21:45hendrikI will sanatize it and move it to the normal wiki.
21:48hendrikI think these steps will help. To summarize: With the document openly available, all developers can help with phase 0. Keeping Stendhal_Testing up date will be helpful too.
21:49hendrikIn the past with two people working together to do a release, putting much effort into automation was not necessary. But I agree that we should do it now.
21:49hendrikIt reduces mistakes, too.
21:51hendrikAnd of course help from kiheru and markus for the admin-permission stuff is much appriciated.
-->

== PostgreSQL support ==

* Long term possible objective using JSON datatype for rpobject.object
* Adding PostgreSQL support to Marauroa is little work
* Hallo of fame script and website need to support Postgres, too.
* Website
** Website currently uses deprecated old mysql api. It needs to be rewritten using [https://php.net/manual/de/book.pdo.php PDO] anyway to be compatible with the next PHP version
** Old php mysql code and new PDO code will result in doubling the number of database connectings, and having isolated transactions.
** We can do that in (rather large) chunks by converting all the code that goes to the wiki-database first. Then the website database, and finally the game-database.