Fosdem2014

General information

This page is meant to somehow coordinate the small Wesconf taking place at FOSDEM 2014. That is everyone attending should please list him/herself in the list of arrivals and stuff like this. FOSDEM 2014 will take place at the first weekend in Febuary 2014, on Saturday 1st and Sunday 2nd.

• Fosdem - http://fosdem.org/2014/

Wesnoth Hacking Room

Wesnoth will not have a room of its own (though there will be the open source game dev devroom on Saturday where hopefully many Wesnoth devs will participate). Instead we will use one of the "general hacking rooms". So far it is not sure which room it will be, if we do it like the last three years, it will be room number 115 in the building AW1 (okay, new booklet is out, now it is AW1.124). Last year this was the smaller of the two hacking rooms and we had no real problem with conquering (and holding) the first row in this room. There were not too many power outlets, so this year at least Ivanovic will bring one multi-outlet power strip plus some extension cable (5m or something like this). Mordante will (hopefully) also bring a multi-outlet power strip and a 20m extension cable. There is no wired network, everything wireless (and sometimes rather/very unstable!). Beside this you should bring laptops since there are no computers available for hacking.

Short version:

AW1 - Room 117 (at least on Sunday)

Discussions and Results

We usually discuss all sorts of things at FOSDEM, this section is basically a (really short) summary of things that were discussed including their results. First are the discussions that were done "in plenum" with basically all attendees around. At the bottom is an area meant for discussions that were held in sub groups that not all devs might be aware of that were around.

Below you can find a list of things we discussed and that were done during FOSDEM.

GSOC 2014

Discussion if we want to participate in GSOC 2014. First question were possible mentors. Here is a list of the people who were around and somehow willing / able to take on students:

Willing to mentor a "full student":

• Fendrin
• AI
• Trademark

Willing to mentor a student with some other (mentors) support:

• Crab
• Mordante
• Thunderstruck

Proposed candidates to mentor who were not around to oppose:

• Shadowm
• mattsc
• timotei

Basic decision was that we would like to try to participate in GSoC. Now we "just" need to find ideas. Proposals:

• Eclipse UMC plugin (adjustments to new editor feature) (fendrin)
• Add-On server related tasks (Trademark)
• AI tasks
• Game engine and MP campaign support improvements (e.g. interface cleanup)
• Work on the ingame help
• AddOns for the editor (fendrin)
• Work on things helping the ladder community (competitive gameplay) without creating bad competitiveness in our MP server
• Better support for "extra resources" (to harvest / collect) to be usable for UMC creators in addition to the existing gold
• Check old project list for usable stuff

More ideas are always welcome. The details will need to be written and more discussion should take place on the ML, in the forums and in IRC.

SDL2 / OpenGL

Does the migration to SDL2 make sense? Reason against is that Debian stable does not support it (yet) but it is in testing. Mobile ports like iPhone / Android significantly benefit from it. Gamepad support is also improved. Valve hired the person who started SDL and is heavily pushing for it, too.

It will be a lot of work to really make it work. One interesting question is if we directly want to move our rendering engine for OpenGL. When moving to OpenGL we will probably have to touch the rendering engine anyway.

Moving to OpenGL will create even more work overall, but since it was talked about for ages this would be a good option to finally get to it. Yes, the early builds will not be as perfect as they could be, but it should be good enough for a start... Mordante already stated that he would be interested to look into it.

The switch to OpenGL also is a great time where we can clean up some ancient parts of the code. E.g. we still have OS2, AmigaOS and BeOS related ifdefs in our code. Those which are no longer supported should be removed. If we find further ones, those should also be removed. Thanks to version control things can still be restored/reimplemented once the ports get active again.

Next stable release

We want to participate in GSoC. This means we need to handle things a little differently regarding string and feature freeze. The proposal is as follows:

1. Get the last string and feature changes into git master until Saturday, February 22nd.
2. On February 23rd: release of "first beta" and branch off from master to "1.12 series branch".
3. Stabilization for 2 month in this 1.12 branch, in parallel normal development going on in master (but devs should focus on bugfixes where possible while Mordante breaks master with libsdl2/OpenGL changes)
4. Release of 1.12 at the end of April / beginning of May.

Add-On Server

The add-on servers content list is a mess right now. It is really difficult to find the "good" content vs the bad/broken content.

Possible solutions:

• Connection to some forum thread where "polling" takes place.
• Make it a "database" separate to the add-on server in which "votes" can be stored. Possible votes:
  • "I like it"
  • "I dislike it"
  • "It is broken"
  • "It is inappropriate"
  • "Star based rating"
• separate add-on servers, one for known good content, one for new / experimental (probably not good because the experimental server will get almost no visits)
• add a flag to known good add-ons showing them as "recommended by the team" ("team" e.g. based on trusted forum users)

How to handle "outdated" votes. Votes / comments could be weighted based on age of the vote.

What we need to do next is decide which steps we should take and what would make most sense. Looking at the current list of add-ons at the server we could use some better ways to handle things because otherwise there is just too much to find good content "fast". We can't expect users to first visit 30 forum threads to find the decent add-ons.

Mapformat

Proposal to drop the following from the format of the map_data tag:

• usage=
• border_size=

The reason is that border_size is assumed to be 1 for mainline, otherwise some parts will break. Usage is always map, so there is no need to separate it. For cases where "=mask" a different WML tag is used already. This proposed change basically means that the wesnoth map editor will no longer write the tag. If the lines exist, the engine will just ignore them as it basically does right now.

Server infrastructure

The old server costs more than $1500 a year. It is only used for email right now. This is too much which is why the contract will be terminated. All services which are still left on the old machine will be lost unless someone ports them. AI already mentioned in IRC that he can work on migrating the mail setup.

GUI / input handling

The ingame help (unit descriptions) suck right now. it neither works well on large screens nor on small ones. The portraits use a lot of space (they are gorgeous!) and improved placement could improve this dialog. While changing something there we should directly consider moving to GUI2. This would mean the helpbrowser needs to be converted to GUI2.

Add-Ons should be able to add/modify things in the helpbrowser. This e.g. means that changed unit properties should somehow be reflected nicely in the sidebar and the help or the help entries should at least be marked that they feature the "base unit" / information and not the changed one. Mainline already does some stuff there, but it is a more pressing need for Add-Ons where the unit modifications can be changing many more things.

What about the "final" complete move to GUI2? The problem is that we either need to clone Mordante or find more people able to help with it and really cooperate on it. What is missing right now are improved listboxes and dynamic content is problematic. Besides tab-support is completely missing. Radio buttons are "sort of implemented" but it should be possible to easily implement them for real as listboxes. Once the foundation is laid many dialogs need to be converted. Replacing theme WML by GUI2 elements is still far away and a huge tasks which requires special widgets.

Besides it is not trivial to change the UI. Other systems like Qt or GTK often offer graphical editors to define the UI setup to ease the creation of the interface definition. Afterwards textual changes are still possible but often not required.

Overall work on GUI2 should probably be handled after the work on SDL2 / OpenGL because rendering is heavily influencing GUI2. If we decide to move to SDL2 / OpenGL it make sense to first get this done and then continue work on the GUI2.

SOCI / Add-On Server (Deamon)

The add-on server could be a 'side project' not directly integrated in the Wesnoth codebase. It still needs to be able to run on our own server which uses Debian stable. Trademark would like to use C++11 for the add-on server. This would be a reason for splitting it from the game but we still have the problem that we need to add some extra / more recent libs if C++11 was used. Right now the add-on server is not reusable for other projects which is a reason for keeping it in our base. The question is basically how well we can separate the add-on server from the game and if there would really be a different user for the system.

It might be a good idea to use the add-on server as a testbed for C++11. This would be the start of using it in Wesnoth but would first give us an idea about how the code looks and how well it works. We will need to think about how to move existing code and if to move "mainline" code over to C++11 (plus when).

The conclusion was that we can keep the add-on server in our server for the moment. If we really find it is reusable for other projects we can still move it outside of the wesnoth repository. We just need to make sure to keep it "separated" somehow in our codebase. But splitting it is not the main goal.

Trademark will complete this entry later on after further discussion.

How to improve communication with 'external'

People agreed that it would make sense to e.g. have some kind of "devblog". The question is who is going to write content. Probably everyone with commit access should be allowed to write something. If someone without commit access wants to write something, we should provide some focal points who would then publish it as "3rd party" post. Every developer should be encouraged to write posts about important things (like groundbreaking changes). It would be great if we had someone review the posts to ensure "valid English" is used. This would be best handled by a native English speaker (with writing skills) since we are talking about our external appearance. Maybe we can find someone on the forums who would like to help with this?

Datamining for content feedback

Fendrin mentioned that it might make sense to get back the old campaign stats system. The agreement was that if we reactivate this, we should start with a small dataset like "turns to win, loses, wins". The related problems here are the visualization of the data as well the question how many people will make use of the data. If many use it and we got a good way to show it we could extend upon it.

It should be possible to develop it for a current session since e.g. UMC developer or mainline developer will do lots of save-loading. Data privacy concerns enforce that we only collect anonymous data and can easily opt-out.

Bugtracker / single login

Currently the bugtracker is still at gna.org. This is not well integrated with our repository. It is possible to get the data out of gna. Crab already has done so and was able to basically get such an export working. Afterwards it should be possible to migrate to a different system. This was not tried yet because Crab did not know where to put it.

A proposal is to export it to redmine and host the bugtracker ourselves on Baldras. On the longterm we might think about creating some single login. Right now Jenkins is already using the github credentials. On the other hand the forum login is already shared with the multiplayer server. Currently we host wiki, forum and mp server. It would be desirable to have some single login available. A concern is the data safety with the wiki. What should not be shared is login credentials that work with the wiki and login credentials that allow login to the server itself via SSH.

The question is how we want to handle github, Jenkins and the bugtracker. Here it might make sense to use the github credentials.

This would result in two sets of credentials per (average) developer:

• github, Jenkins, bugtracker (currently discussed: Redmine)
• forum, wiki, mp server, (maybe) add-on server (if concept changes)

What would be an option for this list is to allow users use their forum credentials to login to the bugtracker (if this is technically possible and not conflicting with using github credentials).

Server administrators would in addition have an SSH login to our server. Access to the server is still to be handled by the main server admin(s).

We will need someone to volunteer help setup parts in this and get things together so that everything works nicely.

Culture of discussion

Several of us have the impression that the mood has become a lot more aggressive and negative. This does not only affect the forums with "non developers" but also the IRC chan. This leads to a reduced motivation and a barrier to implementing required changes. The impression also is that some developers join the discussions without first trying to understand what the topic is and providing productive feedback. One example for this is the git move. We had a long discussion and decided to move to sourceforge. Someone came up with "uhm, we could recontact the github folks" and then suddenly, without further discussion, we switch to github with results like a missing commit email list. This can lead to hurt feelings resulting in people reconsidering if they want to spend their time for the project.

The question here is how we can work together in a more constructive way? We will always come to points where we disagree on a topic and can't find a consensus. It is probably a bad idea to just fork the project and have two games as a result which do extremely similar things. It is especially important that nobody feels threatened with things like "we could remove your commit privileges if you don't give in". As far as we over here are aware we are all peers with no clearly defined "management infrastructure" which will always have the last word. In the past we sometimes asked Dave for help in situations where reaching a consensus was not possible but we should face that he is no longer active in the project.

So do we perhaps need to find and define someone as "decision leader" in case we end in a stalemate? This would *only* be valid for case where a stalemate is reached otherwise and the position would not be based on the tasks handled in the project (e.g. releases, administration, coding, artwork, ...). This can only make sense if we discuss things on a technical level wherever possible. Since we are a game it is hard to keep out the social perspective among our users, but we should not base it on the social interactions between developers.

In general it might be a good idea to come back to discussing larger changes in the open upfront. Here we need to make sure to keep the discussion open and not directly have everyone else jump in shutting down any attempt based on "we have always done it this way" or "I don't like it because I don't like it because I don't like it ...".

Group Picture

No group picture was taken during FOSDEM 2014.

Previous Years

• FOSDEM 2013 wiki page
• FOSDEM 2012 wiki page
• FOSDEM 2011 wiki page
• FOSDEM 2010 wiki page
• FOSDEM 2009 wiki page
• 2008 wiki page, Forum topic (with group photo), Summary of FOSDEM 2008 results