Present: hoijui, jK, Kloot, Tobi, zerver
_Agenda_____________________________________________________________________
- Welcome
- Something about agenda
- May abma become a springdev?
- Progress of stuff to be done before release
- Anyone knows of some testing that happened?
- Mantis 1919
- Simplify version string (in infolog)
- Divide financial power
- Next meeting
- Anything else? (WVTTK)
_Main Conclusions___________________________________________________________
- reactivate the Subversion & Git repositories subforum and rename it to Dedicated Developer Discussion
- abma may get commit access (and becomes a springdev)
- LUS desync will be fixed with table.remove (optional benchmarking may happen after RC)
- Spring-Headless will depend on DevIL (even when Ubuntu/Debian link it to X11)
_The meeting________________________________________________________________
Something about agenda
Tobi: I just added this cause I think we wasted a bit too much time in past meetings on points that just weren't deleted since the meeting before
Tobi: so I suggest that the one who makes minutes removes (nearly) everything from agenda after he has copied them
Tobi: so that then during the week the relevant items can be added, instead of us piling up irrelevant items

Tobi: opinions?
hoijui: hmm..
hoijui: financial power separation.. is not yet done
hoijui: devil for headless neither, and the versioning thing....
hoijui: there is a problem with .. when downloading source from github, we can not inject a file with the version
hoijui: thats why i left these 3 in
hoijui: about devil..
Tobi: ok I added them again
hoijui: it is used for height-map in SM3 directly, as you said
Tobi: but in general?
hoijui: and for Bitmap.cpp.. which i guess, is used for the SMF heightmap too?
Tobi: maybe we can cover that when we arrive at that point, ok?
hoijui: or how is that oen loaded
hoijui: k

Kloot: maybe ongoing points from previous meetings can just be move to a separate etherpad page
hoijui: in general.. sure, is good to remove old stuff, if it is not needed
hoijui: hmm.. cant see why
Kloot: so we dont have to discuss them every time
hoijui: but if they are not done, they shoudl be discussed every time
hoijui: if nothing new is to say, it is just one title plus one line in the meetings.. who cares
hoijui: worked of for the buildbot eg
hoijui: also keeps pressure up to actually finnish that stuff
* zerver has joined #meeting
zerver: hi
Kloot: doubtful, but w/e
Tobi: I think meetings should be better used to discuss things that need discussing, and e.g. mantis or so for on-going stuff (though I realise it doesn't work as smoothly as I write it in practice)
Tobi: hey zerver
hoijui: hello!
zerver: sry, was programming some stuff and forgot the time
hoijui: hmm..
hoijui: it is a bit .. unpractical, as.. apart from the meeting, it is hard to reach yo uguys
hoijui: in case i want to contact all of you
jK: yeah
Tobi: probably that is the root cause yeah, I definitely agree with that
Tobi: that's one of the reasons I started with doing meetings

hoijui: mm :D
hoijui: we need soemthign liek a mailinglist of spring devs, but .. les ugly
hoijui: less*
jK: still some of those discussions could be moved into etherpad
hoijui: or a subforum only for us?
hoijui: hmm yeah
Tobi: in a way, there is a subforum
hoijui: :D the SVN one?
Tobi: but forum has problem that you need to explicitly check it to see if there are new things
Tobi: yeah
hoijui: ..mm true
Tobi: mailing list I would answer faster, at least for clear questions that don't require much thinking to answer

hoijui: we could just comment arbitrary commits on github
hoijui: mmm
hoijui: yeah...
Tobi: could re-instate mailing lists
Tobi: when the one we had was alive it worked reasonably well
hoijui: mmm ok
hoijui: i would be fine wiht that
hoijui: .. others?
hoijui: you fear me spamming you? :D
zerver: mailing list seems very old fashioned
zerver: but i guess the spame makes faster replies
hoijui: yeah true.. thats what i dont like.. only had bad experiences so far
hoijui: mm
Tobi: other option could be google wave, since I'm using that now for some other projects I might answer stuff on that faster too
Tobi: but if those other projects happen to move to other ways of communications it might slow down again..
hoijui: it is comparable to etherpad?
Tobi: yes, works less well on making single doc with multiple people IMO, but OTOH it has threaded replies everywhere in text etc.
Tobi: but I don't know if everyone likes to use a lot of different systems

hoijui: mm..
hoijui: maybe try mailinglists first
hoijui: if the system is good..
Kloot: I don't see how needing to check if there are new posts on forum is more of a disadvantage than needing to check email for new discussions
hoijui: i just remember them as.. write a mail.. and sometime later.. it might appear somewhere...
zerver: I check email like once a day, so for me mailing list would be slower than the forum
hoijui: ok...
hoijui: but as i remember, the SVN forum has a lot of other users.. eg AF can get there too
Tobi: yeah
Kloot: so just remove them from it? ;p
hoijui: yeah.. ok
Kloot: if we're going to reuse it for this purpose
Tobi: sure
hoijui: soudns good.. it is not really used for anythign else
Tobi: will be easier anyway than setting up ML
hoijui: mm
jK: perhaps we should rename it then?
hoijui: ok then.. for today, lets discuss all stuff in the meeting still, and next meeting, the ongoing stuff can be handled in that forum already?
Kloot: Dedicated Developer Discussion
Tobi: nice alliteration

jK: :D
zerver: :)
hoijui: :D
Tobi: anyone against?
hoijui: is good
Tobi: visibility for the forum, same as now?
hoijui: only for us devs
jK: why?
jK: it would help to get new devs
Tobi: users with posting access in the forum, matching those who can push directly to spring account on github?
hoijui: hmm ok
zerver: to discuss sensitive matters, exploits?
hoijui: yeah
jK: exploits are discussed on mantis
hoijui: maybe have a sub sub forum for sensitive stuff? :D
hoijui: yeah true.. explits never were really private
jK: they were private on mantis
hoijui: and usualyl not foudn by us anyway
hoijui: mmm
Tobi: there are enough alternatives for the occasional thing that needs to be kept private, I think (like mantis indeed)
Tobi: or like part of meeting that's not put in minutes
hoijui: ok. everyone sees then
Tobi: so visibility public, access matching those who can push to github.com/spring or more?
zerver: yeah
jK: just spring devs and maybe future ones
zerver: more... on demand only
zerver: by request i mean
Tobi: sure, can always change it
May abma become a springdev?
hoijui: about abma..
hoijui: he kind of did the path finder
hoijui: just needs mergeing
zerver: he fixed it?
hoijui: (plus changes that jk will do in the future, or was it kloot?)
hoijui: he made it modular
hoijui: as in.. plugin-able
jK: I did some this night

hoijui: ahh :D
zerver: nice
jK: so do you want to merge them or do you request commit access for him?
hoijui: both
hoijui: well.. the merge can also be doen after the release..
hoijui: though.. i dont think it is muhc dangerous
Kloot: merging after release was my plan
hoijui: but woudl be nice if we coudl take him in..
hoijui: mm
hoijui: what about commit access?
Kloot: unless release takes 4 more weeks
hoijui: i think he is quite sensible
hoijui: wont be changeing big stuff without advise, if he does not know well..
hoijui: i mean...
Tobi: I think it is fine if you think so, I'm not active enough lately to form a good opinion about him
hoijui: its also a service for the oepn source community.. to educate new devs.. we cant await them to arive here perfectly already
hoijui: ok..
hoijui: jk and kloot saw his repo
jK: +1
hoijui:

Tobi: +anyone who arrives perfectly will probably be leaving pretty soon anyway cause then it's just boring (nothing to learn)
hoijui: yeah
zerver: indeed
jK: (trepan ^^)
hoijui: kloot?
Kloot: well.. learning new things isn't the only reason why you might want to join ofc
hoijui: we can apply a bit different rules at start .. like.. everyone has right to revert all his commits without asking..

Tobi: lol no

zerver: wtf
hoijui: yeah i just mean.. if there are doubts still
hoijui: ok then... ill do it
hoijui: as kloot does not really want to say anything
hoijui: next
Tobi: like we said earlier, iirc, in principle, put comments on the commit, only if it completely blocks your work revert a commit
Kloot: anyway I have not seen enough to judge how well abma knows the engine
hoijui: he does not know it well
hoijui: mm
hoijui: but he already is better in git then you

hoijui: eg.. uses branches
Kloot: oooh, subtle
hoijui: sorry
hoijui: but ... isnt it true that you do not liek fancy git stuff?
jK: does he have any ideas what to do with his new pathfinder interface?
Kloot: no, it isn't
Kloot: just laziness
hoijui: mm ok
hoijui: jk, what do you mean?
hoijui: it never was planned for him to write an implementation
jK: what are his plans when he got commit access?
hoijui: next plan is, to modularize the in game commands (eg /skip, /cheat, ..)
jK: ah yeah saw that forum thread
Tobi: I vote +0, we really need some new devs imo
Tobi: (+0 means 'I don't feel strongly about it, but I'm okey with this.' source: http://apache.org/foundation/voting.html)
hoijui: hehe
hoijui: sorry kloot..
Kloot: to be clear, he _wants_ to be a dev right?
hoijui: i dont want to have a war agasint you... am really just pissed in general these days
hoijui: yes he wants to
Kloot: pissed in general about spring stuff? or IRL?
hoijui: IRL
Kloot: ok
zerver: did you throw out any sub-par devs so far?
Kloot: that's not a good attitude to have when a part of a team though

Tobi: zerver: don't think that happened ever
hoijui: yeah well...
zerver: ok, most ppl eventually learn i guess
hoijui: zerver.. no. there are few that want to be dev and have time .. abma is the first one so far
Tobi: anyway can we reach a consensus on this one, since it's only the second point?
zerver: i have nothing against new devs
hoijui: i ma generally pissed, and then.. whe nsoemthign small happens.. liek now.. when you jsut did not want to say anything, even doh you were agasint it somehow.. and i had to ask liek 3 times...
hoijui: then the piss comes out already
hoijui: hehe :D
zerver: especially if their patches indicate that they can write code, devs are very welcome
hoijui: yeah kloot
hoijui: he also studied the code guidelines, and asked for stuff..
Tobi: anyone wants to veto it and or delay decision until next week? if not then I think you can him to the repo hoijui
Kloot: I am not "against" it, I just think the standard for new devs should a bit higher
hoijui: yeah but.. then you have to say that..
Kloot: overall I'd say I am +0 too
hoijui: and how shoudl it be higher.. what tests or rules?
hoijui: ok then..
Kloot: it used to be submit several good patches ==> access
hoijui: lets take abma in, and define rules somewhen, for the next new one
hoijui: ok
hoijui: yeah.. he did patches for the Python AI Interface
hoijui: they were good
hoijui: not big stuff
hoijui: but.. adjusted it to work well with cmake and other stuff
hoijui: knows qutie soem cmake too, by now
hoijui: ok ill add him, next
Progress of stuff to be done before release
Tobi: didn't have time yet to make real build unfortunately
jK: there is still the LUS desync
Tobi: I think we should tick off mantis #1919 now the cause is know, I added that as the next point
Tobi: is there anything else besides me needing to find a chunk of time?
jK: yeah, imo it could be solved after RC too
jK: because it rarely cause desyncs
hoijui: the mouse in windowed mode under linux is really weird now
hoijui: first of all, it is in drag mode at start
hoijui: (even when spring does not have focus)
jK: after zerver's commit?
jK: or before too?
hoijui: plus it makes the selection sound when i click on somethign outside of spring (eg an other tab)
hoijui: yeah i guess zervers commit
hoijui: (s)
hoijui: very recent that is
zerver: hm
zerver: i guess my last commit 10 mins ago did not solve that?
hoijui: i will try..
Anyone knows of some testing that happened?
hoijui: hehe :D
jK: SirMav did a lot singleplayer testing
hoijui: mm

Tobi: ok
Tobi: have there been some MP games or is that unknown?
jK: non known
hoijui: abma and zydox played vs AI
Tobi: ok
zerver: i tried joining the testing server many times, but no one there
hoijui: but .. i dont remember the outcome
jK: also many users just wanted to test it but failed at broken mods ...
hoijui: yeah.. the topic in #playtest sais to go to an other server
hoijui: mm :/
jK: still it's not our problem when mods fail, but it is annoying when users make us responsible for it ...
Tobi: maybe we could have a small list of known compatible mods
Tobi: anyway it seems good enough to take risk of making 0.82

zerver: lol a bake and shake release
jK: I prefer a RC
Tobi: 0.82 would be rc
jK: k
zerver: just wait for my widget list scrollbar, it is near done
Tobi: if it seems good we put it live a few weeks later, if not we make 0.82.1, .2, etc.
hoijui: mmm
jK: so you want to wait for LUS fix?
Tobi: I'd do a quick fix myself I think before making it (i.e. when I have enough time anyway)
Tobi: guess we can switch to that subject now
Mantis 1919
Tobi: * http://springrts.com/mantis/view.php?id=1919
Tobi: * http://github.com/spring/spring/commit/ ... a900c1b13b
Tobi: * http://lua-users.org/lists/lua-l/2010-01/msg00199.html
jK: k
jK: what's the fastest fix (performance wise)?
Tobi: would need to implement all fixes and measure to really know, but I'd guess trepan's patch or removing items from array with a marker
Tobi: i.e. set removed element to false and test for that where it's used
Kloot: or changing the LVM to assign id's to coroutines :X
jK: does trepan's patch make table creation or table insertion in a table-key slower?
Tobi: no clue
jK: still trepan's patch would need to be cleaned up (we don't want readonly tables, do we?)
Tobi: that kind of stuff really need to be measured to know it, and that takes a lot of time to do properly (in particular cause of lack of test suite)
Tobi: yeah
Tobi: that will be the most work
Tobi: for quick fix I think I'd just take the table.remove fix
jK: trepan always need to make such huge patches >:/
Tobi: if it appears to be too slow we can always fix that later

hoijui: :D
Tobi: and it's the only solution that doesn't require any code additions, just some small changes, I think
jK: only S44 is using LUS exclusive?
Tobi: not S44
Tobi: only some of those newer mods
Tobi: The Cursed and another one IIRC
jK: The Cursed uses it inclusive afaik
Tobi: just to check, what do you mean with exclusive/inclusive?
jK: (nearly) none COB
Tobi: ok
Tobi: then we are speaking about the same thing :-0
Tobi: *

jK: :)
jK: else it won't be a preformance problem at all (yet)
Tobi: I say table.remove, when measurements show it's a bottleneck optimise it
jK: it's hard to measure later
Tobi: why?
jK: because it is inside lua
jK: so gprof won't catch it
Tobi: but why would it be easier to measure now?
jK: it isn't, but now we know of the problem

hoijui: :D :D
hoijui: isn't trepans patch usefull anyway? also for other stuff?
hoijui: so even wiht the quick fix, it should probably included somewhen (?)
Tobi: yeah in slightly longer term I think the ordered keys part may be useful to have
jK: yeah, it may prevent future luarules desyncs (written by unexperienced coders)
zerver: perhaps not a good idea to risk adding a bottleneck this near rc...
Tobi: haven't seen any demand personally for the other parts, so I'd prefer to not include those (to minimise changes compared to native Lua)
jK: still it would need some benchmarking to check fow slow trepans patch is
Tobi: still a better idea than accidentally not (correctly) fixing a desync
Tobi: performance should always come after correctness, although I also fell into that trap when making LUS
jK: ^^
hoijui:

hoijui: next?
Tobi: Kloot, as the main debugger of this issue, have anything to ad?
Tobi: *add
Tobi: so conclusion is we take table.remove fix + a TODO saying that performance could be improved? :)
Kloot: not really since it's your code ^^
Tobi: (and if someone feels motivated he can look at trepans patch

jK: I wonder if making a new table and sorting it by the threadids isn't faster :/
zerver: I am puzzled that the patch is written in lua
jK: (in Destroy)
zerver: I thouht something like this would be part of the core, thus C++ or similar
Tobi: [LCC]jK: I'm pretty sure same bug is in Signal
Kloot: trepan's patch is c++
Kloot: it modifies the lua vm
zerver: ok, sry then, i misread it
simplify version string (in infolog)
Kloot: but imo it's just too large to consider as a fix for this issue
Tobi: yes, I agree with that, at least for short term
jK: k quick fix for RC, and maybe a some benchmarking before release
hoijui: i wrote to github support, to ask for "Download Source" pre-archiving hook
hoijui: we coudl then run:
hoijui: git describe > VERSION.txt
hoijui: and incude that
Tobi: nice
Tobi: though it would surprise me if they make a generic hook, but who knows
hoijui: otherwise, we would not have the version info available, when buildign from the source tarball downloaded from github
hoijui: yeah..
hoijui: well.. they seem quite responsive, and adding new stuff still..
hoijui: so .. i put it on ice, until this one is cleared
Tobi: it arent really official tarballs anyway IMO
hoijui: hmm
Tobi: did you put what you want to do in the issue?
hoijui: yes
hoijui: http://support.github.com/discussions/f ... iving-hook
Tobi: maybe they could be more willing to implement something specific to put output of git-describe somewhere, than allowing arbitrary code
hoijui: sadly, cuase i am so pissed... i feel unable to write a nice sounding request
hoijui: hmm
Tobi: I think it's good
hoijui: i will suggest that, if they wont answer in a few days
hoijui: next
Tobi: nah, it's good as it is IMO
Tobi: ok
HL
DevIL on hl systems
hoijui: aehm...
hoijui: yeah as said..
hoijui: il is only really used in those two places
hoijui: Bitmap.cpp and in SM3
hoijui: for the heightmap
jK: I grep'ed for Bitmap in rts/map/smf/ and didn't found any usage in synced code
jK: so it is sm3 only
hoijui: ok
hoijui: any idea how i coudl get rid of it, except dropping SM3 support?
jK: just drop it
hoijui: ok
jK: print a warning or something like that
Tobi: for short term that may be fine
hoijui: il try that for next week then
Tobi: for long term I don't agree with that
hoijui: for long term?
Tobi: it means we force ourselves to use non-standard custom formats for any data that is used in synced code
Tobi: *image data
hoijui: mm..
Tobi: i.e. the nice thing about sm3 using images, is that no conversion tool (mapconv) is necessary
hoijui: i will just write a wiki with the headless-devil compile instructions
hoijui: and no stub it at all
hoijui: least work
hoijui: and future proof
hoijui: (practically have that wiki done already, mostly)
Tobi: by removing support for loading any kind of image format in synced, that means to fix sm3, we need to invent a new image format, and a compiler, etc. etc.
hoijui: not that there woudl be many that realyl run spring headless on a real headless system
hoijui: mm
Tobi: yeah that too
Kloot: we would not necessarily need our own img format, just support for a non-binary one
Kloot: eg .ppm
Tobi: hmm no, binary or non-binary isn't the right distinction I think, we could just put in our own .bmp or .tga loader
Kloot: although backward compat would be hard to maintain without devil
Tobi: but I think that is an ugly hack, since there is a lib available that can read all those image formats already :)
hoijui: yeah..
hoijui: it is not good to create a lot of extra work just for real headless spring
hoijui: that may be 2 users in total
hoijui: better we let them compile devil themselfs
hoijui: it is not too hard
Tobi: yeah, I also say don't spent too much time on it
jK: yup, it is obviously a linux packager issue
hoijui: mmm
Tobi: yeah that
Tobi: [ARP]hoijui_g5: is the entire HL point covered now or should we still do the 2 remaining sub points?
hoijui: covered
Tobi: ok
divide financial power
Tobi: I put this back also, but I don't know if there's anything to discuss wrt this?
hoijui: :D
hoijui: well.. just if there is anythign new
hoijui: we would need licho i guess
Tobi: yeah well it was sort of decided that I will pursue making an organisation account
Tobi: but realistically that will take a while
hoijui: ok ..
Next meeting
hoijui: sorry then
Tobi: np
Tobi: we might make it just within 2 hours

hoijui: :D
hoijui: i will be in france, at an open air, organized by a family member
hoijui: might get some of the piss out.. i hope!
hoijui: next weekend, that is
Tobi: ok
Tobi: as far as I know now I'm available this time next week for meeting
zerver: me too, i think
Kloot: and me afaics
Tobi: [LCC]jK?
jK: I hope
Tobi: ok
jK: there is a wedding at friday and family is coming
zerver: ouch, there goes another one
hoijui:

hoijui: lets declare it family weekend!!
hoijui: off-spring
zerver: :) :)
Tobi: hmm ok
hoijui: ahh abma might be around!
Tobi: ah ok
Tobi: I think then it's good to try to do a meeting anyway, even though it might be short