Present: hoijui, jK, Kloot, Tobi, zerver
- Review meeting minutes past meeting
- Is it good that i'm moderator/scribe all the time?
- Review 'how shall we keep track of who's doing what?'
- Progress of stuff to be done before release
- GPL - Make dev statement thread? (like for game content)
- OS X (progress)
- MT official build (progress)
- Auto-Revert commits that fail compiling
- Password protection for connecting to game server
- Buildbot structure
- of what do we want an installer built?
- windows/linux test builds
- multiple branches
- Next meeting
- Anything else? (WVTTK)
- RC in ~2weeks
- there will be a developer statement related to AIs&GPL
- we want a OSX dev in our team
- lobbies may need to put passwords in their script.txt's
Review meeting minutes past meeting
Tobi: anything about them?
Tobi: should I have censored them or was it ok?
hoijui: well.. in theory yes, but i forgot about it too, and AF would have rambled anyway
zerver: I don't we should censor anything unless someone really slips
hoijui: so it does not matter
hoijui: it was just for.. so we could first talk to AF personally
hoijui: so .. next point
Is it good that i'm moderator/scribe all the time?
(we decided to make a rotating list)
Review 'how shall we keep track of who's doing what?'
(we decided to create an additional etherpad, so we now got "doing now", "longterm", "meetings agenda")
Progress of stuff to be done before release
jK: as you may have seen, I finally fixed the sticky keys issue :)
Tobi: past week we added jK to it because you had most points :)
hoijui: abma and me fixed the installer
hoijui: but i also found out that the boost I compiled for MinGW 4.4 is bad (at least i think it is), as it uses SJLJ instead of Dwarf2
hoijui: tried to get a dwarf2 MinGW today, but failed so far
jK: left in the render engine are: the reverted ssmf shader issues (varying limits) and some shadow conflicts
Tobi: I still need to fix the crash on malformed attack command; all other engine things on my todo aren't blocking
hoijui: and there is still zervers stuff
hoijui: currently, only unitsync linkage is failing because of it
Tobi: I fixed that
hoijui: ah ok
jK: BlockShot & TargetWeight not working in LUS should be fixed before next release, too
Tobi: makes sense, adding to to do
hoijui: or any more stuff left to be done for release?
Tobi: I've made my blocking points in to do list bold
jK: k, a vague timeline for next release perhaps?
Tobi: 2 weeks ago it was 4-5 weeks to RC IIRC
jK: I would say 2weeks to RC
jK: or need someone more time?
Tobi: ok, as of now I think 2 weeks should be possible
- RC in ~2weeks
- hoijui will continue his efforts with boost and MinGW4.4
- Tobi will fix malformed attack commands
- Tobi will look at BlockShot & TargetWeight in LUS
- jK will take a look at shadows rendering
GPL - make dev statement thread? (like for game content)
hoijui: looks like AF accepts it, but wants to be the winner/the one who was right/the victim
Tobi: as far as I'm concerned what I said last in that thread still applies - from august or so we make it bit clearer to AI devs that AIs have to be GPL too, just like engine code & mod code
hoijui: mmm ok
Tobi: "make dev statement thread? (like for game content)"
Tobi: suppose we can do that at some point..
jK: yeah, a lot AI devs got that illusion of a special AI exclusion in the license
jK: it needs to be made clear that there isn't such one
hoijui: in the past? cuase by now, AF seems the only one to have released binaries but no source
hoijui: but yeah. should be made clear
hoijui: the subpoint..
jK: also it is even impossible, because such a line would disallow us to use any other GPL code
hoijui: is ok wiht me, though i can not imagine that anyone will read there, if they can not post, and it are only rules for what to do and not to do
Tobi: jK, yeah that too
Tobi: I can do same as for that other 'stance' post, 2 posts, one locked sticky with the info
Tobi: and a link to normal thread for reactions
hoijui: mm ok
zerver: poor line quality...
zerver: or wifi noise
Kloot: at least when it's written down people can not fall back on a possibly misremembered developer stance from five years ago
Tobi: guess I can try to devise a first version in etherpad before next week
hoijui: thinking about it, an etherpad where only we have write access woudl be better then a thread
hoijui: .. yeah :D
hoijui: because in a thread.. it will either get long fast, or when each of one just maintians a single post with edits, there is no new-post notification
hoijui: ..hmm there is neither wiht etherpad though :D
Tobi: it will just be a statement
Tobi: discussions about it are irrelevant
Tobi: like this one http://springrts.com/phpbb/viewtopic.php?f=1&t=17847
zerver: i think forum is better, more clicks less chance ppl will read it
hoijui: i though it will be for dev statements in general
hoijui: you think abotu only this AI exception thing?
hoijui: ah yeah.. that's perfect
hoijui: i said nothing then
- Tobi will make draft for a developer statement related to AIs&GPL
OS X (progress)
hoijui: right now, i am talking with a guy in #sy
hoijui: looks like both master and last release are compiling under OS X
zerver: thats good news
hoijui: and he tested master and at least got to the in-game menu by Aus
hoijui: so.. i propose we take aegis's offer of an OS X VM
jK: we still need an OSX dev in our team
hoijui: the alternative beeing, setting up cross-compiling, but that sounds much uglier, and it is not real test
hoijui: the OS X VM woudl be used as build-slave
Tobi: I forgot to make a post
hoijui: compiling each comit maybe
zerver: wihtout an osx dev we cannot expect this to work for real
hoijui: so we coudl at least keep it compiling there
hoijui: yeah true
Tobi: but I got a promising PM today from someone who asks for OS X forum and wants to collect threads there and would develop on it a bit
hoijui: ahh cool
hoijui: a. request VM from aegis
hoijui: b. make OS X subforum
hoijui: c. aquire regular OS X dev
hoijui: i say we shoudl do as much of this as we can
jK: I would twist a and b
hoijui: ..i woudl say no particular order
hoijui: doing it at the same time
Tobi: c. is already mostly performed by the one requesting the forum
hoijui: or say.. eveyrthign as fast as possible
Tobi: as in, "but I sure am able to do minimal tweaks here on the code when needed."
hoijui: mmm ok
hoijui: maybe remove the linux forum in turn?
hoijui: most stuff in ther could simply be in bugs forum
Tobi: so IMO I just make that forum, give him moderator rights and stuff so he can move threads there, and once forum is there aegis and he / us can discuss a buildslave
jK: don't remove the linux forum, else ppl will forgot to mention that they are using linux
jK: (got that a lot of times in IRC/lobby)
hoijui: mmm.. well, they usualyl should post infolog anyway... but ok
hoijui: lets keep it
Tobi: maybe at some point it could be H&B (no posts), and below that Linux/Mac OS X/Windows, but that's other topic
- make OSX subforum
- request VM from aegis (for buildbot)
- aquire regular OSX dev
MT official build (progress)
jK: my PBO class introduced some new opengl functions, I will try to add them to GML
hoijui: they also need to be added to headless
hoijui: i am usually quite clueles on that
zerver: i got some compile error there, do i have old glew.h or something?
jK: btw is anyone able to update the mingwlibs on builbot?
hoijui: only bibim
hoijui: jk, if i rebase springheadless on current master, and make eveyrthign compile and run except the gl stuff
hoijui: coudl you possible help me fix that?
hoijui: it means adding dummy functions
hoijui: but they are not all the same..
hoijui: i will try myself first
zerver: i commented out two lines in PBO and it compiled so i think there is only one new GL function
zerver: where is the updated mingwlibs?
hoijui: we moved it to git
jK: or you can download them at http://glew.sourceforge.net/
zerver: hoi, did you look at ways to include springmt.exe in the installer?
hoijui: aehm... i dont remember :/
hoijui: ah no..
zerver: i can do it too, but you probably have more cmake skill
hoijui: i wanted to use the springheadless way
hoijui: but that should have master merged in first..
hoijui: but as master was bugged i did not want to do that, ..
hoijui: too muhc ugliness in the way there was, and i did not follow it any further
hoijui: but now that should be solved..
hoijui: will look at it again this week
zerver: thx, need it before next release
hoijui: you want it to be in next release?
zerver: yeah, now or never
hoijui: in general, cmake stuff will have to be more modular
hoijui: so we do not have to copy most of rts/CMakeLists.txt to tools/MT/CMakeLists.txt
hoijui: but part of that (most) is already done in springheadless, as said
hoijui: wil merge that part into master
hoijui: eg.. the list of source files can be shared
hoijui: nm... yeah next point
zerver: if we can get that exe included in the installer, i think this point is done
zerver: if you don't have time, pm me and ill try it
zerver: but i don't even have cmake installed
- hoijui will merge springheadless, so a MT-build can be included with the next engine release
Auto-Revert commits that fail compiling
jK: I see this rarely a problem
hoijui: yeah.. only posible with new buildbot of course
jK: because it mostly affects just buildbot
hoijui: why? no..
jK: it was just a bad timing this time because you worked on it
Tobi: well you do see that stuff keeps breaking more and more without any working buildbot
hoijui: there are quite some people compilign latest master
Tobi: but I don't think a technical solution is needed
hoijui: maybe you do not have to deal with them often
hoijui: but i do..
Tobi: we could just say that it's fine to revert a commit that breaks compiling in a way that blocks you from continuing work
hoijui: most AI devs eg
zerver: it would probably do more harm than help
hoijui: how more harm?
Tobi: but no need to automate it IMO
hoijui: it is not lost, anyone can easily reaply the patch
hoijui: it is still in history
hoijui: you jsut reaply it locally, if it was yours, fix it, commit the fix, and push it with the fix
zerver: sure, possibly bloating the history with reverts
Tobi: that's another reason why I don't think it should be automated
hoijui: yeah true. automation is not good
Tobi: but I think it's fine if we decide that reverting stuff is no prob if it broke some compile
hoijui: yeah that
hoijui: history bloat is not really a problem
Tobi: (AND if it somehow made your work harder AND it isn't trivially easy to solve ;-0)
hoijui: i bet git is smart enough
hoijui: of course
Tobi: well it makes bisections and making logs etc. more work
Tobi: if there's so much broken stuff and we really need automation I'd go for a staging branch
hoijui: well.. the idea is to not commit stuff that breaks compiles anyway
Tobi: with everyone committing to that and automatically merged in master iff it compiles on all platforms / with all configurations
Tobi: BUT atm I think that's overkill
Kloot: I would say only auto-revert broken commits after N minutes/hours
Kloot: it would be a pita otherwise if you made a typo in some commit
Tobi: yeah that too, that's what would result in history spam
Tobi: should only be reverted once it's really blocking someones work
Tobi: and I think it's fine to agree that reverting in that case is fine :)
hoijui: yeah that.. is most important
Tobi: (so that we don't get comment wars on github about such reverts :))
hoijui: :D yeah
hoijui: when i revert something, i dont want it to be seen as a rude act .. as it usually just means i am to stupid to solve it myself, or the author will solve it better
jK: reminds me of my ssmf commit
Tobi: imo if no one disagrees we can move on to next point
jK: there was just 1 bug in it and the whole commit got reverted, and now there is still stuff not recommited
Kloot: only because you made so many changes at once, and I will revert-revert the remaining stuff this week
jK: kk :)
- no auto-revert of failing commits
- reverts should be rare and only if it is blocking someone else's work
Password protection for connecting to game server
Tobi: that is already possible, right?
zerver: Auswasch implemented this password protection some time ago
Tobi: just no lobby client and/or server combo that supports it
zerver: yes, problem is (if I understand correctly) lack of lobby support
hoijui: (reminds me, we shoudl organize lobby server meeting)
zerver: so what do we do about this?
Tobi: hoijui, oh, wanted after all?
hoijui: with aegis
Tobi: kk, thought you were just going to talk to him in pm
hoijui: i did but.. i would be better if yo uand koshi and BD are there too
zerver: i have implemented some stuff that may allow spoofing a reconnection and disconnect the real player
zerver: so in next release, this lack of lobby support is major issue
Tobi: hoijui, I'll try to organise that then
zerver: however, it can only happen if player is timing out, so not huge issue, but still big
zerver: one way would be to REQUIRE password for it to work at all...
Tobi: hmm, I take it disconnecting real player must happen cause otherwise you can't reconnect on new IP without waiting for your old IP conn timing out?
hoijui: BD and especially koshi woudl preffer the lobby server to be in python, as they know it better
hoijui: and i dont want to work on TASServer if it is not wanted
Tobi: ok, lets take that to that future lobby meeting though
hoijui: .. and aegis is willing to do the changes that he needed too
zerver: tobi yes, in some cases this disconnection must occur
hoijui: yep ok
Tobi: I say make it require password to be used
Tobi: then at least we don't have to wait for lobby server before release
Tobi: and it will just work once lobby server supports it
Tobi: which could (hopefully) happen way before next-next spring release
zerver: trust me, that support will never come in that case..
zerver: i am also working on another reconnection that allows dropped player to rejoin and spectate
zerver: this also would benefit from password protection
hoijui: you need me to add something to TASServer?
hoijui: if i know what exactly, i can do it
hoijui: if i get specification
Tobi: hmm well suppose that's true, so change plan for release to include 'wait for new TASServer' as first step?
zerver: basically each player needs a password in the start script
Tobi: no, I can't agree with myself there - we just release and don't bother with a potential gap in time in which some exploit might be possible
Tobi: I hate it to reintroduce strong coupling between server/lobby/engine releases
hoijui: so when i get a start script that has a user without password, i reject it?
Tobi: otoh lobbies are already coupled due to unitsync breaking changes I think..
zerver: no, you generate a password for each user
Kloot: true but in a much more minor way
zerver: server gets all passwords, user gets only one password
Tobi: Kloot, yeah but still in a way that old lobby + new unitsync = crash, right?
hoijui: i will look at it, and may ask questions to you afterwards, or to koshi
Kloot: yeah, but a one-line change is probably more acceptable to lobby devs than generating unique password per user would be :)
zerver: exploit is only possible if someone is timing out already, so this is a small issue imo
- we will force passwords in script.txt in the future
Tobi: I was working on setting up old style buildbot again
Tobi: and wondered what kind of builders and stuff we want at first
Tobi: now it's one builder (still called springlobby <_<)
Tobi: making win32 stuff for like all configurations
Tobi: and also, it makes installer of everything
Tobi: since that takes relatively huge amount of time (making installer takes approx. same time as compiling spring from scratch)
Tobi: my first q is: of what do we want an installer built?
hoijui: btw... most of hte time compiling the installer is spent for compression (and downloading the additional stuff to include, like springlobby
Tobi: second (less specific) question is: how should structure look?
Tobi: brb 1 min again
hoijui: if everythign is downloaded, and compression is off, it takes aroudn 5 seconds on my machine
Kloot: the master branch with default cmake params should imo always have an installer
Kloot: just to reduce testing barrier for people
Kloot: (mod devs in particular)
hoijui: maybe we should try zlib compression instead of lzma, if it is much faster, it would probably be better for everything except master default release build
hoijui: worst thing is, packing a debug build with lzma
Tobi: but otoh, that one time someone really wants debug / syncdebug / whatever build he can just take regular installer and put new spring.exe in it, right?
Tobi: everything else is the same
hoijui: AI and ai interfaces :/
Tobi: ah right
hoijui: is it also possible to manually request builds?
hoijui: becuase if so, then we really only have to create installers for the default one..
hoijui: and only create instalelrs for other stuff on manual requests
Tobi: yeah I can try to change structure to one column = only one branch+configuration
Tobi: it will give a huge amount of columns ofc but apart from the display that doesn't really matter
Tobi: it's actually how it was in the past, IIRC
Tobi: ok I'll do that I think I got enough input, you can always suggest changes at any time anyway
hoijui: mm ok
- Tobi will continue his work on buildbot-waterfall
hoijui: same is ok for me
Tobi: for me too
Tobi: Kloot, ok with you?
Tobi: zerver: same everything ok with you?
zerver: maybe during summer meetings should be further apart?
zerver: but next week is ok for me too
Kloot: I think so, might have some IRL thing coming up though
hoijui: will you invite the OS X guy next meeting?
Tobi: I'd prefer just shorter meetings to less frequent, although if many people happen to be away we can decide to skip some weeks..
split of "Progress of stuff to be done before release": new configHandler?
hoijui: zerver, this new class, GlobalConfig...
zerver: yes, purpose of globalconfig is to never have to read same config value in two places
jK: yeah, I dislike that new GlobalConfig class, too
zerver: there is a risk of two different default values if you need the config in two places...
jK: perhaps read the configs into the classes directly as the other do, too?
hoijui: yeah.. it seems less ugly to possibly have two different default values then this new class
hoijui: yeah... can we not check for different default values at runtime, inside config handler (eg, only if DEBUG is activated)
Tobi: imo confighandler should have the list of defaults built in, and other code shouldn't have any magic constants as defaults
zerver: but thats super ugly
hoijui: yeah or that.. though, this has the downside of having to modify config handler whenever you add a new config setting somewhere
Kloot: needing to read same value in two completely different places is somewhat suspect in the first place imo
Tobi: zerver: why? at least you get everything for the 'interface' configfile together (easy to tell someone what defaults are etc..)
jK: on the other side you could also add description to each configtag this way
Tobi: also you can add documentation etc.
hoijui: yeah true
zerver: config should be read in one place imo. period.
Tobi: like e.g. Doxygen does it, where it writes huge manual into config file when config file doesn't exist :)
Tobi: that definitely, that is in ConfigHandler
hoijui: if we are talking about config handling changes already..
hoijui: there is also the issue of eg headless spring
hoijui: where other defaults are usefull
Tobi: (btw I don't know if it's good idea to go deep into technical discussion again inside the meeting)
hoijui: and actually... if you want to run normal and headless spring on the same PC, it is bad if they share the same config
zerver: i first though about putting the global config directly in confighandler but then changed my mind
hoijui: hehe :D
hoijui: yeah ok, true
hoijui: maybe we discuss this after the meeting?
Kloot: you could introduce a confighandlerproxy (with #ifdefs corresponding to headless/normal buildtype) that forwards all calls
hoijui: less work for jk, and its not really interesting for users
hoijui: hmm yeah
jK: maybe true, but it is worth to discuss after the metting
hoijui: i also want to do that
Tobi: for now I don't mind, config system as it is now has more issues (no persistent comments, indeed default values spread out over multiple places, gadget/widget/engine keys all in one namespace, no way to have systemwide + per user + per mod config, etc.)
hoijui: yeah.. we could maybe even start a forum thread then
Anything else? (WVTTK)
jK: confighandler ideas?
jK: perhaps we should wait with those till next release?
hoijui: that comes after End
Tobi: well we never yet did a really official end :)
hoijui: i say we discuss, and if we find a solution we like someone implements it
hoijui: and if it is pre release, it is ok
hoijui: i dont see much potential problems there
hoijui: or why wait, jk?
zerver: feel free to change it as you like and discard globalconfig, but config value should be read in one with one default value place imo
Tobi: apart for what I mentioned: <quote>for now I don't mind, config system as it is now has more issues (no persistent comments, indeed default values spread out over multiple places, gadget/widget/engine keys all in one namespace, no way to have systemwide + per user + per mod config, etc.)) I don't remember more issues etc.</quote>
Tobi: and I got to go now, I'll comment in some other way than meeting if I see stuff I really don't agree with in log :)
hoijui: if hte defautl value is not given when the value is read, we do not have to restirct places in where it is read
Kloot: k, bye
jK: hoij, there seems a lot to do till next release, I don't know if there is anyone available to implement such ideas
hoijui: ah ok
jK: "default values spread out over multiple places" > that would be solved via an extended configHandler, which holds defaults+descriptions
jK: "gadget/widget/engine keys all in one namespace" > this is a widget/gadget dev issue, the wiki mentions that lua shouldn't save in those (lua has its own configfiles)
hoijui: what if we have a file for the defaults(+descriptions) ?
hoijui: instead of integrating them into the config handler
jK: like that config.xml we had a long time ago?
hoijui: it would allow game devs to supply thier own defaults
hoijui: no idea.. i guess that was before my time
hoijui: .. i mean, if they ship wiht thier own installer
hoijui: what was that thing that kloot said..
hoijui: overriding soemthing...
Kloot: proxy class for confighandler
hoijui: ah yeah
Kloot: which could read the defaults from a file or have them hardcoded / #ifdef'ed
jK: this would need somechanges in the way configs are saved
jK: atm it never checks the defaults again after spring run once and saved the configfile
Kloot: unless springrc/settings is read-only
hoijui: yeah, headless spring eg, shoud lhave a different config file then normal spring
hoijui: in addition do different defaults
hoijui: adding a namespace should be easy i guess
hoijui: or .. how exactly is it meant?
hoijui: each widget would only see its own settings eg, plus global stuff?
hoijui: maybe not so easy :D
hoijui: reminds me...
hoijui: we should probably have a kind of .. namespace/hirarchy in general
hoijui: it woudl be usefull for many things
hoijui: logging, config, drawing restrictions
jK: I dislike namespaces in configfiles somehow
hoijui: sending messages
jK: no matter what this can wait till release/RC
hoijui: yeah ok
- wait with new configHandler till next engine release?