Dev meeting minutes 2010-05-30

Dev meeting minutes 2010-05-30

Minutes of the meetings between Spring developers are archived here.
User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

Dev meeting minutes 2010-05-30

Post by jK » 30 May 2010, 23:03

Date: 2010-05-30
Present: hoijui, jK, Kloot, Tobi, zerver

_Agenda_____________________________________________________________________
  • Welcome
  • 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)

_Main Conclusions___________________________________________________________
  • 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



_The meeting________________________________________________________________
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
Tobi: ok

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: mm :-)
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
zerver: k
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
hoijui: but...
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

main points:
  • 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
hoijui: mmm
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
hoijui: :D
hoijui: hey
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
hoijui: mm
Tobi: yep
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
Tobi: why?
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
hoijui: aha..
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: yes

main points:
  • 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: yeah :-)
hoijui: so.. i propose we take aegis's offer of an OS X VM
jK: we still need an OSX dev in our team
Tobi: back
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: so:
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
jK: kk
hoijui: or say.. eveyrthign as fast as possible
hoijui: mm
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
hoijui: ok
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

main points:
  • 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: hmm..
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: yup
jK: btw is anyone able to update the mingwlibs on builbot?
hoijui: only bibim
jK: k :(
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
jK: sure
hoijui: thanks :-)
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: k
Tobi: http://github.com/spring/mingwlibs
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?
hoijui: ok
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
zerver: ah
hoijui: wil merge that part into master
hoijui: eg.. the list of source files can be shared
Tobi: ok
hoijui: nm... yeah next point
zerver: if we can get that exe included in the installer, i think this point is done
hoijui: mm
zerver: if you don't have time, pm me and ill try it
hoijui: ok
zerver: but i don't even have cmake installed :P
jK: o_O
hoijui: :D :P

main points:
  • hoijui will merge springheadless, so a MT-build can be included with the next engine release



Auto-Revert commits that fail compiling
Tobi: :)
jK: I see this rarely a problem
hoijui: yeah.. only posible with new buildbot of course
hoijui: ?
jK: because it mostly affects just buildbot
hoijui: aehm...
hoijui: why? no..
jK: it was just a bad timing this time because you worked on it
hoijui: no..
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: ok
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: yeah
hoijui: of course
Tobi: well it makes bisections and making logs etc. more work
hoijui: mmm
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
hoijui: hmm
Tobi: BUT atm I think that's overkill
hoijui: ..yeah
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
hoijui: mm
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 :x
Tobi: imo if no one disagrees we can move on to next point
hoijui: yep
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 :)

main points:
  • 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 :P
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: yes
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
Tobi: ok
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
hoijui: ok..
hoijui: ok
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: ok
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

main points:
  • we will force passwords in script.txt in the future



Buildbot structure
Tobi: I was working on setting up old style buildbot again
Tobi: http://springrts.com:7778/waterfall
Tobi: and wondered what kind of builders and stuff we want at first
Tobi: now it's one builder (still called springlobby <_<)
hoijui: :D
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
hoijui: yeah
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: no..
hoijui: AI and ai interfaces :/
Tobi: ah right
hoijui: well...
hoijui: is it also possible to manually request builds?
Tobi: yes
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
hoijui: mm :-)
Tobi: yeah I can try to change structure to one column = only one branch+configuration
hoijui: mmm
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
hoijui: yeah :-)
Tobi: ok I'll do that I think I got enough input, you can always suggest changes at any time anyway
hoijui: mm ok :-)

main points:
  • Tobi will continue his work on buildbot-waterfall



Next meeting
hoijui: same is ok for me
Tobi: for me too
jK: 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
Tobi: ok
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..
Tobi: sure


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
zerver: really?
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.
Tobi: yeah
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: yep
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: :D
hoijui: ok
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 :)
Tobi: laters
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
hoijui: 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
jK: bye
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
hoijui: mm
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

main points:
  • wait with new configHandler till next engine release?
0 x

User avatar
Jazcash
Posts: 5302
Joined: 08 Dec 2007, 17:39

Re: Dev meeting minutes 2010-05-30

Post by Jazcash » 30 May 2010, 23:29

I'm glad the MT build is being taken more seriously now. It's definitely a key part of maximizing performance for players. If any game needs proper MT support, it's Spring, what with the hundreds/thousands of units and what not.
0 x

SirMaverick
Posts: 834
Joined: 19 May 2009, 21:10

Re: Dev meeting minutes 2010-05-30

Post by SirMaverick » 30 May 2010, 23:40

jK wrote:
  • lobbies may need to put passwords in their script.txt's
It's about time to use that. We have that feature for almost a year now.
0 x

User avatar
bibim
Lobby Developer
Posts: 901
Joined: 06 Dec 2007, 11:12

Re: Dev meeting minutes 2010-05-30

Post by bibim » 30 May 2010, 23:57

jK wrote:jK: btw is anyone able to update the mingwlibs on builbot?
hoijui: only bibim
jK: k :(
I'm not connected to spring lobby very often, but if there are still things to be updated in BuildServ before the new buildbot is fully operational, don't hesitate to send me a forum PM. It sends me an email and usually I answer quite fast....
jK wrote:Password protection for connecting to game server
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
zerver: however, it can only happen if player is timing out, so not huge issue, but still big
Actually it's already possible to spoof/dos players from the start (without even being in the battle at the beginning), so I don't think it will make a big difference ;) (more info in this mantis report)
jK wrote:hoijui: so when i get a start script that has a user without password, i reject it?
zerver: no, you generate a password for each user
zerver: server gets all passwords, user gets only one password
hoijui: ok
hoijui: i will look at it, and may ask questions to you afterwards, or to koshi
There are also some info about a way to implement it in the mantis report.
0 x

zerver
Spring Developer
Posts: 1358
Joined: 16 Dec 2006, 20:59

Re: Dev meeting minutes 2010-05-30

Post by zerver » 31 May 2010, 19:17

Yes, at game start spoofing is not only possible, but happens on a regular basis due to some lobby bugs. To be disconnected in mid-game is much more annoying though.
0 x

User avatar
AF
AI Developer
Posts: 20669
Joined: 14 Sep 2004, 11:32

Re: Dev meeting minutes 2010-05-30

Post by AF » 31 May 2010, 20:05

May I note that AIs should be GPL compatible, e.g. PD GPL or LGPL etc, enforcing GPL licenses and only GPL licenses on the AIs would actually violate the GPL license of spring. Subtle terminology difference, but a world of pain between them
0 x

User avatar
bibim
Lobby Developer
Posts: 901
Joined: 06 Dec 2007, 11:12

Re: Dev meeting minutes 2010-05-30

Post by bibim » 31 May 2010, 20:27

zerver wrote:Yes, at game start spoofing is not only possible, but happens on a regular basis due to some lobby bugs.
What? You mean some lobby clients write the wrong player name in the start script? :shock:
0 x

User avatar
Pxtl
Posts: 6112
Joined: 23 Oct 2004, 01:43

Re: Dev meeting minutes 2010-05-30

Post by Pxtl » 31 May 2010, 20:33

AF wrote:May I note that AIs should be GPL compatible, e.g. PD GPL or LGPL etc, enforcing GPL licenses and only GPL licenses on the AIs would actually violate the GPL license of spring. Subtle terminology difference, but a world of pain between them
Well, any non-GPL (but GPL-compatible) license used with a Spring AI will be functionally GPL as long as it's used for the Spring engine, since any derivative AI based on an existing AI that works with Spring will also need to be GPL compatible, and that's the essential meaning of the GPL - "anything you do with GPL code must also be GPL".

The only time non-GPL license would come into play would be if somebody was, adapting a Spring-based AI to another engine.
0 x

User avatar
AF
AI Developer
Posts: 20669
Joined: 14 Sep 2004, 11:32

Re: Dev meeting minutes 2010-05-30

Post by AF » 31 May 2010, 21:33

Pxtl, your making a lot of assumptions.

If the devs release a statement saying all AIs must be GPL, then it doesn't matter what your interpretation of the GPL license is, because it is violated by the literal meaning of the statement.

There are reasons for using GPL compatible licenses that are not themselves GPL, other than porting to other engineers, otherwise the very question of using GPL in the first place would have held no merit to the SYs.

There are a lot of use cases, and an infinity of use cases we cannot foresee, that are possible with GPL compatible licenses, forcing the particular GPL license itself is a step too far, and a dangerous path to take, if only because it means there is no legal ground to stand on for prosecuting or enforcing springs license against any rogue developer who comes along with an AI and says "Im never ever opensourcing my AI, look I ran it through allsorts of encryption and obfuscators, cus your never gonna get it!"

It would be far more appropriate to say:
AIs must have a license compatible with the GPL <insert version> license under which spring is licensed.
Followed by a short paragraph detailing what will happen in various situations, e.g. what will be done to non-compliers, and the time scales within which someone must opensource and comply with the request. Simply saying it must be GPL, would be both irresponsible, and invalidate springs own license.
0 x

User avatar
Pxtl
Posts: 6112
Joined: 23 Oct 2004, 01:43

Re: Dev meeting minutes 2010-05-30

Post by Pxtl » 31 May 2010, 22:01

GPL licences states that derivative works must be licensed under the GPL, and considers anything that links to GPL-licensed code as a derivative work.

Full stop.


So even if you offer your code under a more permissive license, it must be converted to the GPL to run on Spring. The alternate options presented by your licensing would only be usable if all the Spring-specific code was gutted out, making it no longer a derivative work of the Spring engine.

"GPL Compatible" means that a product can be re-licensed as GPL without permission of the owner. That's all. That's why all GPL Compatible licenses are more permissive than the GPL - because you can convert something with a more permissive license into a less permissive one without contacting the owner, since re-licensing is a permission granted. It means that if somebody else using your source wanted to release it under the GPL, they could. That's all.

And obviously, there are no licenses that are both GPL compatible and more restrictive than the GPL.

Here's why GPL Compatible becomes important: Gord writes G, Monty writes M, and Biff writes B. G is licensed under the GPL, M is licensed under an incompatible MS license, and B is licensed under BSD.

Kevin wants to make a program K that uses G, M, and B. Because he uses G, his project _must_ be GPL since it is a derivative work. This means that all the components within - including G, M, and B, must also be GPL.

B can be re-licensed as GPL because it is GPL-compatible. M cannot. So, he cannot incorporate M into his project... but he can include B. However, the version of B he's using? He's releasing that under the GPL license, NOT the BSD license. The original version is under the BSD license, but by bundling it within a GPL project it is being released under a GPL license.

If he makes any modifications to B, he can still release it separate from K under the BSD license... but if any of those modifications specifically link to G or K, he _must_ release it under the GPL and only the GPL.

That's how GPL-Compatible works. He didn't have to bug Biff to get permission to re-license under GPL, because the license is already compatible with the GPL, that's all.

edit: Consider the BSD license - it states that you're getting the code and can do whatever you want with it. You can even modify it and claim it as your own, as a closed-source product and nobody will ever see your modifications.

Now, the BSD is GPL-compatible in the sense I described above. However, think about your interpretation - that something BSD licensed is BSD licensed even when interacting with a GPL program. Well the BSD license gives you permission to close the source of your modifications. So, then, if you released Shard under the BSD license, and I made Shard2... and closed the source... but it still ran the Spring engine... then I have complied with Shard's BSD license while violating Spring's GPL. This is absurd on the face of it.

So realistically, any non-GPL license you release under is going to have the caveat attached that all references and usage of the Spring engine will need to be gutted out before you can use it in non-GPL fashions.

The only other case I can think of is if somebody wants to make an app "C" that controls Shard, which, in turn, controls a Spring player. I suppose that, under the LGPL, "C" could be closed-source while Shard and Spring remain open. On the surface of it, this is in violation of Spring's GPL - if Shard is running on Spring, it is GPL. Therefore, if "C" is controlling Shard which is controlling Spring, then C must be GPL too. This is why people describe the GPL as "infectious".

*note: this comment is base on my knowledge of GPLV2... may not apply to GPLV3.
** Also, I disagree with the EFF's assertion that linking is a derivative work, but this is the interpretation that the EFF, the Spring Project, and every other devotee of the GPL supports. It has never been tested in court.
0 x

User avatar
AF
AI Developer
Posts: 20669
Joined: 14 Sep 2004, 11:32

Re: Dev meeting minutes 2010-05-30

Post by AF » 31 May 2010, 22:51

GPL licences states that derivative works must be licensed under the GPL, and considers anything that links to GPL-licensed code as a derivative work.
Your entire posts rests upon this starting opening sentence, which relies upon an assumption, which is incorrect.

Regardless of the valididy of this point, it is made utterly irrelevant by the fact that AI != Engine. AIs are not derivative works of the engine.

I repeat again, AIs are not derivative works of the spring engine.

If AIs are derivative works, then so are lua widgets, lua gadgets, maps, etc etc. AIs link to the engine yes, but they are not derived from the engine, they are not based on the engine, they have their own code bases, they just use the API exported by spring.

Eitherway your interpretation of the GPL would make a large number of high profile projects illegal. It has been said by many people.

A license is stated as being compatible with the GPL, if it provides the same freedoms, or more, than the GPL allows. Any restrictions a license places on a product that are in addition to the GPL would violate the GPL license of the associated project unless written legal permission is acquired and presented from the license holder.

In future please, refer to the GPL to fact check, or even the previous threads we've had on GPL, where you yourself have stated the very claim I have made.
0 x

User avatar
AF
AI Developer
Posts: 20669
Joined: 14 Sep 2004, 11:32

Re: Dev meeting minutes 2010-05-30

Post by AF » 31 May 2010, 22:56

To be precise:

http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL
If a library is released under the GPL (not the LGPL), does that mean that any program which uses it has to be under the GPL or a GPL-compatible license?
Yes, because the program as it is actually run includes the library.
And Again, further on:

http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins
If a program released under the GPL uses plug-ins, what are the requirements for the licenses of a plug-in?
It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them.

If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed.

If the program dynamically links plug-ins, but the communication between them is limited to invoking the ÔÇÿmainÔÇÖ function of the plug-in with some options and waiting for it to return, that is a borderline case.
0 x

User avatar
Neddie
Community Lead
Posts: 9406
Joined: 10 Apr 2006, 05:05

Re: Dev meeting minutes 2010-05-30

Post by Neddie » 31 May 2010, 23:02

I was already planning to split OS X out of the Linux subforum.

The EEF's assertions on the subject of linking are in regards to GPL v3. This is a major reason why I do not use GPL v3 and why I consider Spring and and the various GPL titles to be explicitly GPL v2, even where they say v2 or later.
0 x

User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6109
Joined: 29 Apr 2005, 01:14

Re: Dev meeting minutes 2010-05-30

Post by FLOZi » 01 Jun 2010, 03:52

If AIs are derivative works, then so are lua widgets, lua gadgets, maps, etc etc
Is that not the exact stance taken by the engine devs wrt lua? :|

(Annoyingly enough, I can't easily find the announcement of that decision, so epic fail there as how is anyone new to the engine supposed to be aware of it.)
0 x

User avatar
hoijui
Former Engine Dev
Posts: 4342
Joined: 22 Sep 2007, 09:51

Re: Dev meeting minutes 2010-05-30

Post by hoijui » 01 Jun 2010, 08:30

AF, with both these quotes you are actually proving exactly what Pxtl explained. I guess you just understood him wrong. And to be precise, Spring Skirmish AIs (at least definitely all native ones) fall under what is described in the 2nd paragraph of the second quote in your last post (before this). They are dynamically linked, and they do not fall into the border-case of the 3rd paragraph.
0 x

User avatar
AF
AI Developer
Posts: 20669
Joined: 14 Sep 2004, 11:32

Re: Dev meeting minutes 2010-05-30

Post by AF » 01 Jun 2010, 14:16

Is that not the exact stance taken by the engine devs wrt lua?
As I remember it, the devs took that stance for two reasons:
  • Lua gadgets/widgets use the spring APIs and are thus linked as defined in the GPL and must be GPL compatible
  • Trepans gadget handler code was licensed as GPL, which kinda makes the above point moot anyway
There is still nothing stopping you from licensing gadgets and widgets as Public Domain or LGPL however, since they are GPL compatible licenses.
AF, with both these quotes you are actually proving exactly what Pxtl explained. I guess you just understood him wrong. And to be precise, Spring Skirmish AIs (at least definitely all native ones) fall under what is described in the 2nd paragraph of the second quote in your last post (before this). They are dynamically linked, and they do not fall into the border-case of the 3rd paragraph.
Not at all, I was referring mostly to paragraph 2 myself.

Pxtls point is that if it links to GPL code ist HAS to be GPL.

My point is if that if it links to GPL code, it has to be GPL or GPL compatible, and enforcing just GPL, and not allowing the GPL compatible licenses, would violate springs own license.

Under Pxtls interpretation, all our libraries must therefore be GPL licensed. But lua is not under a GPL license, it is under the MIT license, and although it is GPL compatible, it is not GPL, therefore according to Pxtl, it is illegal to use Lua in spring if spring is GPL, but this is clearly not the case. We should not mince words and put down a statement of official policy if the policy is itself in violation of our license, else we risk invalidating it, and causing damage to the AI community. It doesn't matter what the intention behind it is if its there, we have to assume people will read its literal meaning.
0 x

User avatar
hoijui
Former Engine Dev
Posts: 4342
Joined: 22 Sep 2007, 09:51

Re: Dev meeting minutes 2010-05-30

Post by hoijui » 01 Jun 2010, 14:59

no, you understood Pxtl wrong.

When we say Spring AIs have to be GPL, that is correct.
You can put Shard in the public domain or make it BSD licensed, but effectively, when used with spring, it is still GPL.
you might have some part in your code that is useful for others independently of spring. lets say, an MD5 algorithm. if someone else wants to use that in his calendar application (totally unrelated to Shard or spring) and Shard is PD, then he does not have to make his app GPL (could be closed source, eg.). but if he uses Shard directly, for example adds a plugin to it that writes graphs, this stuff has to be GPL too, which means he can use GPL, BSD or PD, but not closed source.
0 x

User avatar
AF
AI Developer
Posts: 20669
Joined: 14 Sep 2004, 11:32

Re: Dev meeting minutes 2010-05-30

Post by AF » 01 Jun 2010, 15:44

Thats fine, but what you mean and what you say do not match when you say 'AIs must be GPL'. This statement specifically says AIs have to be GPL licensed, they can only be GPL licensed, and any other license is forbidden. That is the literal meaning of what it says, and it is innacurate and misleading. That is my point.

It is far more accurate to say that AIs must be licensed under a be GPL compatible license, and states categorically what is meant, rather than requiring a brand new MTR GPL thread for every time a nonGPL AI is released with a compatible license and someone who is not a long term member of this community sees the sticky and raises the point.
0 x

User avatar
hoijui
Former Engine Dev
Posts: 4342
Joined: 22 Sep 2007, 09:51

Re: Dev meeting minutes 2010-05-30

Post by hoijui » 01 Jun 2010, 17:38

We got your point since some time already. Saying they must be GPL is correct too, that is what Pxtl tried to explain, cause if you say something has to be GPL, it always means it has to be GPL compatible. But due to noobs possibly not getting that, an explanation would not hurt, if we create a whole new thread anyway.
0 x

User avatar
AF
AI Developer
Posts: 20669
Joined: 14 Sep 2004, 11:32

Re: Dev meeting minutes 2010-05-30

Post by AF » 01 Jun 2010, 19:28

As long as its clarified I'm good with it.
0 x

Post Reply

Return to “Meeting Minutes”