Present: _koshi_, hoijui, abma, zerver, jK, Tobi
Misc.
<hoijui> so...
<hoijui> :D
<zerver> yawn
<zerver> i think we need a release to get some action in here
<hoijui> :D
<hoijui> Tobi, can you probably suggest how to best what abma suggests in his comment here?
<hoijui> http://springrts.com/mantis/view.php?id=2642
<hoijui> the problem with AIs and bandwidth limit has ot be done before a release, definitely
<zerver> I don't understand the design choice to make AI:s different from real players
<zerver> I would never have taken that route if I implemented it
<hoijui> i guess it was just easier that way
<zerver> maybe
<hoijui> woooot!
<hoijui> jk is in hte us
<jK> ?
<zerver> some proxy maybe
<jK> need to use ircbridge (not at home)
<hoijui> ah k
<hoijui> ddint know we have such one in the US
<jK> possibly it detects the ip of the irc webclient
<hoijui> what else..
<hoijui> ahhh
<hoijui> we coudl now do the change to the develop branch
<hoijui> as Tobi is back
<hoijui> we said it may make sense to wait for him, in case something in the buildbot needs a root present
<hoijui> means, we would fix a date (at best, right now i guess), where we start to use develop, isntead of master
<hoijui> and only one of us will touch master after that
<hoijui> hmm..
<hoijui> buildbot should probably build both master and devellop from now on
<hoijui> when we do the release, we will set master HEAD to develop HEAD a last tiem, and form then on, they will be separate
<hoijui> so, we add a buildbot stuff for branch develop (equal to what we have for master)
<hoijui> when that is done, we can all switch to develop
<jK> [RoX]Tobi
<Tobi> hmm ok
<hoijui> changeing name locally, when you need to do it (you shoudl be on master), dont do yet: git checkout -b develop master
<Tobi> so when is the idea we will switch?
<hoijui> though you may have to set the tracking branch then
<hoijui> when the buildbot is setup to build branch develop
<Tobi> ok
<hoijui> and .. that could be doen now.. or.. tomorow i guess
<hoijui> can it all be done in the spring repo?
<hoijui> or cna some stuff onyl be done by you?
<Tobi> master would need a restart
<hoijui> ok
<Tobi> abma and you can do that too iirc
<Tobi> but I guess I know most about buildbot
<hoijui> ahh k
<hoijui> yeah
<Tobi> I can do it on wednesday, am occupied tomorrow and now its a bit late to start on something imho
<hoijui> ook, thanks
<Tobi> I'll probably push some test crap to develop then at first, to test buildbot setup, before finishing with force push that makes it equal to master again
<hoijui> ook
<hoijui> so nobody use develop until tobi says so
<Tobi> anyway I can make a post on the forum when buildbot builds it
<hoijui> perfect
<Tobi> kk
<zerver> ok
conclusions:
- Tobi will make buildbot build develop branch
- when this is done we switch to it
<jK> he couldn't relicense it (duno why), still he allowed us to use his version as base for our own implementation
<hoijui> mmm ok...
<hoijui> but is that .. possible?
<hoijui> i mena, if he .. disapears
<hoijui> and someone says spring uses that code
<hoijui> which it does..
<hoijui> then what?
<jK> sure, you are always allowed to write your own implementation, as long as you don't copy paste (or violate any IP)
<hoijui> mm ok
<hoijui> so yo will not copy paste anything?
<hoijui> change all var names.. stuff like that?
<hoijui> is it very small?
<jK> he said I should take his code and rename the variables, but I will rewrite it totally (also needed to fix a bug in it)
<hoijui> ok
<hoijui>
<jK> it's just a very nice source to see how to do it and I will still credit him
<hoijui> ok. good
conclusions:
- he can't relicense, but he allows us to use his version as a reference for our own implementation
<hoijui> thats stil in from last time?
<hoijui> guess does not need to be here
<hoijui> or did we agree to reevaluate it now?
<hoijui> i didnt do anything
<jK> no it was moved to this meeting
conclusions:
- no progress
<Tobi> can that even be done on github?
<hoijui> yeah exactly Tobi, that is also what i odnt know..
<hoijui> an other project i work in has such hooks, but they setup thier own git server
<hoijui> i tried to find out once... but i ma still not sure
<hoijui> github does not mention this kind of hooks
<hoijui> i guess they could be abused
<Tobi> I don't think it is possible, I've never seen such a thing in the admin interface
<Tobi> yeah
<hoijui> mmm yeah i guess so too
<Tobi> oh, ppl could install it locally in their repo ofc
<Tobi> if it is a pre-commit hook that is where it should be
<Tobi> was confusing it with pre-receive or so
<hoijui> ahhh..
<Tobi> nothing that can be 100% enforced though
<hoijui> yeah
<hoijui> that shure could be done, and is a good idea i think
<Tobi> better first have good coding standards and only then when enforcing using wooden stick doesn't work think about this
<hoijui> :D
<hoijui> one sentence got into the other?
<Tobi> too much subsentences and lack of commas, I guess
<hoijui> :D ok
<hoijui> yeah well..
<hoijui> in the other project, the hook-enforced standards are pretty low
<hoijui> i dont even remember...
<hoijui> something like.. very basic white-space ugliness
<hoijui> and it makes sure you don't submit files of certian types (eg microsoft word)
<hoijui> or certain binaries
<hoijui> the thing is, if you make strict rules with hooks, then the whole repo has to conform to these rules, or else you can not commit anymore
<hoijui> thats with the hook on hte receiving end, at least
<hoijui> so if you do a clean commit on an unclean repo, and want to push, it fails
<Tobi> sure?
<Tobi> might depend on the code in the hook though
<hoijui> yeah possible
<hoijui> but it is either the stadnard, or not preventable even
<hoijui> i forgot why it is so
<hoijui> it also makes sense kind of...
<hoijui> if oyu think about it..
<hoijui> eve nif all uf us used the hooks locally
<hoijui> contributors woudl not
<Tobi> in any case I don't really believe in technically enforcing such things, I'd rather see good standard + comments on github when stuff doesn't adhere to it + quick improvement of ppl so those comments are seldomly needed after a few weeks/months
<Tobi> yeah true
<hoijui> aif we used githubs pull request stuff
<hoijui> yeah, that woudl be better
<Tobi> if we actually have a way to check whether code adheres to 'our standard', then we could run it on buildbot too
<hoijui> btw zerver, you still do "type *name" sometimes
<Tobi> i.e., build fails if code doesn't adhere to standard
<hoijui> ahh yeah
<hoijui> true..
<Tobi> or continues but is still marked red
<hoijui> good idea
<hoijui> next?
<Tobi> sure, if there is anything left
conclusions:
- not possible on github
- pre-commit hook for every dev could work, but isn't strictly enforcing (in particular w.r.t. merging from outside contributors...)
- possibly best option: run a style check on buildbot
<jK> added by abma
<Tobi> he told me that in private too, I've looked at it quickly and it seems nice
<jK> I am happy with current etherpad, except memleaks all few months
<Tobi> seems much more lightweight than normal etherpad (not surprising since it's nodejs instead of rhino on jvm), and has approx. same feature set
<Tobi> IMHO we migrate once I figured out how to migrate the database
<Tobi> or rather, once I figured that out I can make a test instance with our content so we can try
<hoijui> nice!
<jK> don't forget that we aren't the only ones that use the current etherpad
<Tobi> kk, will do public test then
- etherpad lite is an etherpad clone fully in javascript, with nodejs on the server
- Tobi tried this, looks promising: much less resources needed than etherpad, and identical (or at least similar) feature set
- Tobi will continue with a migration to this as time allows
[00:12] ** abma_irc joined the channel.
<abma> hi! :-/
<jK> hi
<abma> this was added by me, Beherith asked me when is meeting and if he maybe can take part
<abma> it looks like he is offline, so skip this
<jK> then we are finished
<abma> kloot: maybe you can help in this thread: http://springrts.com/phpbb/viewtopic.php?f=12&t=26776
<jK> help? the thread contains nothing
<abma> Beherith asks for a summary how the unsynced heigtmap is implemented in .83
<hoijui> koshi wanted to ask us something
<jK> that's like asking how sun works
<jK> he needs to be more precious
python wrapper for unitsync
<hoijui> koshi made(makes) a python wrapper for unitsync
<hoijui> and wants to know if/how to integrate it into the spring repo
<hoijui> most importantly, he needs to use a wrapper tool (forgot the name), whihc he said is not packaged by the linuxes
<abma> jk: yes, true. i think he doesn't what to ask for... so its more a incremental thread... more specific question more specific answers
<hoijui> so it probably would have to be in rts/lib or in a subdir of his wrapper (whihc would make sense if it would be a submodule
<abma> pybindgen?
<hoijui> yep, that coudl be it
<hoijui> ill invite koshi
[00:20] ** _koshi_ joined the channel.
<_koshi_> hi
<hoijui> hey
<hoijui> i just bascially explained that you did a unitsync python wrapper
<hoijui> and that it requries pybindgen
<hoijui> which is not packaged in linuxes
<_koshi_> debian
<_koshi_> dunno about redhat
<_koshi_> or source distros
<jK> hoij, why should such a wrapper be in rts/lib/ ?
<hoijui> hmm yeha i guess it shoudl not
<_koshi_> sidenote: wrapper is somewhat of a misnomer. this actually compiles a shared object file that is directly loadable as a python module
<_koshi_> and that object file does not depend on libunitsync shared object
<Tobi> what is the advantage compared to a python module with ctypes?
<_koshi_> aside from the automation, this could be versioned for diff unitsync versions in the future
<_koshi_> with ctype you'd have to handle loading diff unitsync so yourself
<jK> how does that matter
<jK> when we have multiple engine version support we need a diff interface no matter what
<jK> and even, with your module you still need to load different module for different version
<jK> so you just replace lib with module
<_koshi_> no
<_koshi_> you'd be needing multiple unitsync versions and wrappers with ctypes
<_koshi_> with the self contained lib/module you only need that
conclusions:
- koshi made python bindings for unitsync
- con: requires pybindgen, which isn't packaged in any major Linux distros
- advantages are a bit unclear
- no decisions made
