Dev meeting minutes 2010-12-20

Dev meeting minutes 2010-12-20

Minutes of the meetings between Spring developers are archived here.
zerver
Spring Developer
Posts: 1358
Joined: 16 Dec 2006, 20:59

Dev meeting minutes 2010-12-20

Post by zerver » 21 Dec 2010, 00:44

Present: <abma_irc> <[ARP]hoijui_g5> <[LCC]jK> <Kloot> <[RoX]Tobi> <zerver>

=== Welcome ===
<[ARP]hoijui_g5> all here :-)
<[ARP]hoijui_g5> somehow
<zerver> the absent minded pack

=== replace some static libs with shared ones? (for example md5, 7z) ===
<[ARP]hoijui_g5> http://springrts.com/phpbb/viewtopic.php?f=12&t=24813
<zerver> yeah, we better get started or im gonna go repair my percolator
<[ARP]hoijui_g5> whats that?
<zerver> coffe machine
<[ARP]hoijui_g5> ahh :-)
<[ARP]hoijui_g5> so yeah.. on topic
<zerver> static libs are always better, less files and dependencies
<[ARP]hoijui_g5> the question is, whether we could remove eg 7z lib sources (static lib) and depend on the dyn-lib
<[ARP]hoijui_g5> ?
<zerver> or thats my opinion...
<[ARP]hoijui_g5> The question is more... if we need the sources patched, or if we need always the same version of the lib/src
<[ARP]hoijui_g5> if not, then we should use the dyn lib
<[ARP]hoijui_g5> it means our source base is smaller, less to compile, less to maintain
<[LCC]jK> 7z can be made dynamic
<[ARP]hoijui_g5> bascially, moving the responsibility from us to the distro maintainers
<[ARP]hoijui_g5> ok
<[ARP]hoijui_g5> md5?
<Kloot> an md5 lib should not change often
<Kloot> so probably safe to rely on the distro
<Kloot> 7z updates more regularly afaik
<[LCC]jK> still 7z isn't synced
<[ARP]hoijui_g5> yeah.. that is the important thing
<[ARP]hoijui_g5> synced
<[LCC]jK> so it shouldn't matter, if they change stuff
<[ARP]hoijui_g5> and patches
<[ARP]hoijui_g5> the only candidates in my eyes are 7z, md5 and minizip
<[LCC]jK> yup, only lua & streflop need to be static
<Kloot> 7z is still synced in the sense that extraction must produce bit-for-bit identical files for all archives regardless of version, but that is probably guaranteed
<[ARP]hoijui_g5> oscpack is very small, and does not exist as dyn lib on any distro
<[ARP]hoijui_g5> i think so, yeah
<[ARP]hoijui_g5> the crc is also generated by 7z i think, but that has to be the same one different versions/platforms too
<[ARP]hoijui_g5> in their specs
<[LCC]jK> do we even use the crc from the zips?
<[ARP]hoijui_g5> same for md5 and minizip
<[ARP]hoijui_g5> i think yes
<[ARP]hoijui_g5> just saw it a week ago.. already not sure anymore :D
<[ARP]hoijui_g5> will check...
<[ARP]hoijui_g5> yes we do
<[LCC]jK> :)
<[ARP]hoijui_g5> with both zip and 7z
<[ARP]hoijui_g5> ok so.. these 3 gonna be made dynamic then

Conclusions:
Some source files will be ripped out from the repo and replaced with libs



=== C++ unit testing ===
<[ARP]hoijui_g5> more stuff on the meeting etherpad
<[ARP]hoijui_g5> has anyone of you ever used unit tests in C++?
<[ARP]hoijui_g5> me not
<[ARP]hoijui_g5> not even in java really, but i know that it is more common there
<[LCC]jK> I don't even know how they should help us
<[ARP]hoijui_g5> i woudl like to setup up the basic framework
<[ARP]hoijui_g5> then.. for new stuff, or when bored for old one, we can add them if we want
<[ARP]hoijui_g5> you never used them?
<[LCC]jK> no
<[LCC]jK> didn't even heard of those
<[ARP]hoijui_g5> you can test simple stuff like.. utility functions
<[ARP]hoijui_g5> ah ok
<zerver> me neither
<[ARP]hoijui_g5> most basic unit tests look like this:
<Kloot> unit tests are most useful for code where you know what the result should be
<[ARP]hoijui_g5> yeah
<[LCC]jK> from what I read they should check the interfaces (e.g. checking if streflop always gives the same results)
<Kloot> ie. math functions
<[ARP]hoijui_g5> yeah
<[ARP]hoijui_g5> these tests are most easy to write, cheap to execute, and therefore what you will see most often
<Kloot> dunno how you could write unittesting code for the pathfinder say when the engine keeps changing
<[LCC]jK> but you still need to write those tests yourself, so how do such apps help you to do such things faster than custom ones?
<[ARP]hoijui_g5> yeah that would be very complex.
<[ARP]hoijui_g5> they dont
<[ARP]hoijui_g5> what they do is..
<[ARP]hoijui_g5> they provide itnerfaces to execute the tests, to present the outcomes .. in html for example
<[ARP]hoijui_g5> to alarm devs if a test fails
<[ARP]hoijui_g5> there are also toosl that show you which parts of your code are well covered with tests
<[ARP]hoijui_g5> buildbot frameworks may have support for integrating them
<[ARP]hoijui_g5> in java, this is all very standardised
<[LCC]jK> hmmm so the big work still has developer by writting those tests ...
<[ARP]hoijui_g5> yes
<[LCC]jK> not very helpfull apps ...
<[LCC]jK> -l
<[ARP]hoijui_g5> :D :P
<zerver> it does not seem like friday night entertainment to me
<[ARP]hoijui_g5> well.. it is kind of obvious that you can nto generate these tests automatically
<[RoX]Tobi> unit testing is a technique, not an app, in any case :)
<[LCC]jK> still they use c++ syntax which isn't ... code saving
<[ARP]hoijui_g5> yeah true
<[ARP]hoijui_g5> it is proven that it saves you time, after time
<[ARP]hoijui_g5> also.. this discussion shoudl not be about if we should write unit tests for everything
<[ARP]hoijui_g5> nobody is forced to do that
<[ARP]hoijui_g5> but we shoudl agree on a framework, so if someone wants to write unit tests, he can add them
<[LCC]jK> I wonder what could be tested with those
<[RoX]Tobi> problem with spring is that much of it is legacy code (i.e. not easily testable aka badly designed)
<[ARP]hoijui_g5> and we can slowly build up support for it
<[ARP]hoijui_g5> yeah true
<[ARP]hoijui_g5> ugly code is harder to test
<zerver> possible in theory maybe to apply to spring maybe, but who is gonna do it
<[ARP]hoijui_g5> all utility functions, eg in fuilesystem can be tested
<[ARP]hoijui_g5> as said zerver, that is not the question here
<[RoX]Tobi> https://github.com/tvo/spring/commits/u ... loshandler
<[RoX]Tobi> thats something I did quite a while ago in that direction but didn't really finish it (as in, integrate into master and/or actually write tests)
<[ARP]hoijui_g5> ah :D
<[ARP]hoijui_g5> so.. you wrote your own system?
<[RoX]Tobi> IOW it's just some refactoring until the LosHandler is testable, and then I plumped in some unit testing framework
<[RoX]Tobi> let me check which one
<[RoX]Tobi> ah the boost one
<[LCC]jK> LOS, RayTracing & pathfinder could profit by such tests
<[ARP]hoijui_g5> mm ok
<[LCC]jK> but still, the discussion doesn't make sense if no one plans to write UnitTests in the next 3months
<[ARP]hoijui_g5> i woudl likely write some for file-system
<[RoX]Tobi> it does make sense if someone is willing to set up the infra and make some (example) tests
<[ARP]hoijui_g5> yeah
<[RoX]Tobi> as imo a major reason for not unittesting anything is that now you need to first set up the whole infra :-)
<[ARP]hoijui_g5> yeah ;-)
<[ARP]hoijui_g5> have you done unit testin in C++ before this try, Tobi?
<[RoX]Tobi> no
<[ARP]hoijui_g5> ok
<[RoX]Tobi> Spring is a few orders of magnitude larger than any other C++ codebase I've touched probably anyway (except for a few months of KDE hacking a loooong time ago)
<[ARP]hoijui_g5> as i suggested boost or cpptest, and tobi used boost, i guess that is prime candidate now
<[ARP]hoijui_g5> :D
<[ARP]hoijui_g5> mm k
<[ARP]hoijui_g5> i know from java:
<[ARP]hoijui_g5> you have the sources and the test sources in different dirs, in maven structure for example:
<[ARP]hoijui_g5> src/main/java/
<[ARP]hoijui_g5> src/test/java/
<[ARP]hoijui_g5> in these dirs, you use identical package structures
<[ARP]hoijui_g5> and usualyl you have one class in the test structure per class in the real source
<[ARP]hoijui_g5> src/main/java/mypackage/Util.java
<[ARP]hoijui_g5> src/test/java/mypackage/UtilTest.java
<[LCC]jK> yeah, I would prefer to have them in a diff folder, else they clutter a lot
<[ARP]hoijui_g5> mm
<[LCC]jK> also I don't think we need to keep the same directory structure in the tests dir, because we would never test all classes
<[LCC]jK> I assume there is need for 4-10 tests
<[ARP]hoijui_g5> hmm... i woudl preffer the same structure
<[ARP]hoijui_g5> it does not really hurt
<[ARP]hoijui_g5> in java, they even test GUIs automatically.. for well structured code, you can unit-test nearly everything
<[LCC]jK> it would cause many empty dirs and it is hard to maintain if things change in the rts/ dir
<[ARP]hoijui_g5> often you even get nicer structured code, if you write it to be unit-testable
<[ARP]hoijui_g5> ah.. no empty dirs
<[LCC]jK> even a dir with just dirs is empty
<[ARP]hoijui_g5> you jsut create the dir when you place the first thest there
<[ARP]hoijui_g5> test*
<[ARP]hoijui_g5> when i write a test for FileSystem.h, i create the same relative path
<[ARP]hoijui_g5> before that, the FileSystem/ dir wont exist in the test structure
<[LCC]jK> still you would create an empty system dir
<[LCC]jK> just for its subdir FileSystem
<[ARP]hoijui_g5> yeah..
<[ARP]hoijui_g5> i cant see how this is unclean though
<[RoX]Tobi> I think that is easier than later having to move stuff around when you want to add a test for something in System
<[ARP]hoijui_g5> yeah
<[LCC]jK> I would prefer to add tests/testXYZ for each test
<[LCC]jK> e.g. tests/FileSystem, tests/LOS, tests/RayTracing
<[ARP]hoijui_g5> mmm is not good
<[ARP]hoijui_g5> .. i have worked on many projects with unit tests
<[ARP]hoijui_g5> all of them use the same structure
<[ARP]hoijui_g5> it is just no contra there
<[ARP]hoijui_g5> why would a dir without plain files be unclean?
<[ARP]hoijui_g5> our tools/ dir for example
<[LCC]jK> because when you move dirs in the rts-dir you would have to reorder the same things in the tests-dir
<[ARP]hoijui_g5> had only dirs until recently
<[ARP]hoijui_g5> yeah
<[ARP]hoijui_g5> that is no big deal
<[LCC]jK> it's an extra (non-obvious) step to maintain
<[ARP]hoijui_g5> in the worst case, you can still do that later
<[ARP]hoijui_g5> if you forget it
<[ARP]hoijui_g5> it also happens very seldomly that we move dirs under rts
<[ARP]hoijui_g5> if you do it once, you have to remember, or someone else will notice
<[LCC]jK> but we move files into other dirs from time to time
<[ARP]hoijui_g5> no problem really
<Kloot> the amount of work wrt directory management is probably 0.00001% of getting critical parts of Spring in a unit-testable state in the first place
<[ARP]hoijui_g5> yeah
<[ARP]hoijui_g5> also.. we may get like 10 test classes in the next 2 years at best
<[ARP]hoijui_g5> maybe just trust everyone else who uses this technique.. considering you jsut heard of it today
<[ARP]hoijui_g5> or tobi and me, who know it some
<[ARP]hoijui_g5> so... should we settle for boost (in case anyone wants to start this)?
<[LCC]jK> or what ever the first one prefers >_<
<[LCC]jK> but boost seems lighweight
<[LCC]jK> compared to cpptest
<[ARP]hoijui_g5> mmm
<[ARP]hoijui_g5> ok lets say boost then, and if the first one uses somethign else which is not totally off, thats ok to ;-)
<[ARP]hoijui_g5> next?
<[RoX]Tobi> just pick one and try imo, c++ unit testing stuff is all very messy imo (no clear best framework that everyone uses etc.)
<[ARP]hoijui_g5> mmm appeard like that to me too
<[ARP]hoijui_g5> with C, it seems to be worse even. many more frameworks
<[RoX]Tobi> not in the least because c++ kinda sucks for unit testing because it's unmanaged (so one failing test can crash your whole test framework unless you run each test in separate process)
<[ARP]hoijui_g5> mmm
<[RoX]Tobi> (still applies if you leave out `for unit testing' ;-))
<[ARP]hoijui_g5> :D
<[ARP]hoijui_g5> was thinking the same :D
<Kloot> java unittest the c++ unittests
<[ARP]hoijui_g5> we shoudl just change language
<[ARP]hoijui_g5> hehe :D
<[ARP]hoijui_g5> yeah.. sadly.. i dont think it woudl be best fo both worlds :D ;-)
<[RoX]Tobi> would just mean the tested code can crash the whole JVM :-P
<[ARP]hoijui_g5> yeah. and you still cant use reflection, which is one of the core things that make it nicer in java

Conclusions:
Unit testing is not prohibited, if anyone likes to do it, go ahead



=== git rules ===
<[ARP]hoijui_g5> we already have a git guidelines etherpad
<[LCC]jK> very important is this one: "separate unrelated changes into separate commits"
<[LCC]jK> >_<
<[ARP]hoijui_g5> yeah
<[LCC]jK> we should agree on those guidelines
<[ARP]hoijui_g5> +1
<Kloot> here comes the inquisition :]
<[ARP]hoijui_g5> Kloot is violating them most often
<[ARP]hoijui_g5> yeah.. actually we just want to be mean to you Kloot
<Kloot> I noticed
<[ARP]hoijui_g5> especially me of course
<[ARP]hoijui_g5> it has no rationale behind it
<[ARP]hoijui_g5> you are such a poor boy!
<Kloot> spare the sarcasm bitte
<zerver> separating the changes might be more work than the changes themselves
<[ARP]hoijui_g5> you started that shit again
<Kloot> and you are making really big mountains out of molehills
<[LCC]jK> separating them are jsut few clicks in git-gui
<[ARP]hoijui_g5> thing is this: the way you do it, it is easier for you
<Kloot> I follow regulations to the point that it is still fun to work on this project
<[ARP]hoijui_g5> the guidelines are better for everyone else except the committer
<zerver> it is easy to forget to commit in git gui, and sometimes changes are loosely connected
<[ARP]hoijui_g5> adn evne for the commiter it is better, later on
<[LCC]jK> also Kloot, even merged changes from different files
<[ARP]hoijui_g5> if you make changes to intervoven that it takes more time to separate them then the changes themselfs, you did it totally wrong in the first place
<[ARP]hoijui_g5> just do not change formatting in this case
<[ARP]hoijui_g5> plus i gave instructions and offered help for how to separate easily
<[LCC]jK> you can even merge multiple formatting changes in one commit, but then it should really only contain formatting changes
<zerver> i say that too strict rules takes the fun out of programming
<zerver> you must remember this is volunteers we are talking about
<[LCC]jK> and it makes the live of the other devs much easier
<[ARP]hoijui_g5> it also keeps the fun in for eveyrone else though
<[ARP]hoijui_g5> its a 1 or many decission
<[ARP]hoijui_g5> jk and me follow these rules.. you dont have to tell you what it takes
<[ARP]hoijui_g5> i find it totally acceptable
<Kloot> is this really a project-critical matter to you, or just something you find annoying?
<[LCC]jK> it is the big advantage of git-gui that you can split commits with changes in the same file
<[ARP]hoijui_g5> well... the to things you did this week, which jk commented on
<[LCC]jK> it is really project critical, because I stopped deep-checking many of your commits
<[ARP]hoijui_g5> where you introduced bugs silently..
<zerver> i try to follow the rules too, but im not going to spend 10 minutes hand picking chunks in git gui if i forget to commit
<[ARP]hoijui_g5> that is more then just a bit annoying
<[LCC]jK> it just takes too much time to check them
<Kloot> you know there can be bugs introduced in format-only commits as well
<[ARP]hoijui_g5> yeah
<zerver> hand picking chunks is a risky business too, you might do it wrong
<Kloot> and when you spam those it's just as painful to find them
<[LCC]jK> but they will be more obvious between only formatting changes
<[ARP]hoijui_g5> zerver, genrerally you shoudl not have to do it!
<[ARP]hoijui_g5> you just dont do formatting changes when editing a file
<[ARP]hoijui_g5> if you see formatting problems, you do them after you committed
<[ARP]hoijui_g5> if you cant handle the separating
<[ARP]hoijui_g5> i have a simple script that lets me separate stuff with my favourite GUI diff editor, if it has to be
<[ARP]hoijui_g5> it is no big thing
<[ARP]hoijui_g5> it just shows lack of respect for other devs and anyone else who might be looking at commits
<[ARP]hoijui_g5> if you only care for what is least work for your own
<Kloot> it's using one's judgment to follow the spirit of the rules instead of the letter
<[ARP]hoijui_g5> egoistic judgment
<Kloot> but if this such a principal issue for you, I'll stop
<Kloot> no, I get the sense you are highly personally annoyed and so am I
<[ARP]hoijui_g5> i am annoyed by your egoism causing others more work, yes
<[LCC]jK> I am not annoyed, I am frustrated by the extra work given by others
<Kloot> like checking each of your formatting commits causes more work for me?
<[LCC]jK> you know that each line in those formatting commits needs to do 1:1 the same as before
<[RoX]Tobi> TBH I have to agree with hoijui as I've experienced how epically much longer it takes to make a bugfix release branch by cherry-picking from master when there is no one-to-one match between commits and changes
<Kloot> [LCC]jK, yes, and where there are 1000s in a row...
<[ARP]hoijui_g5> mm that is a reason too
<Kloot> in practice 1:1 match does not last so long anyway when larger changes to the code are made in master
<[ARP]hoijui_g5> when i did some changes in the past you did not like (rightfully so) and told me, and explained, i stopped doing these
<[ARP]hoijui_g5> eg const_cast stuff
<[RoX]Tobi> the 1:1 match will last, it is simply conceptual; there is no need for the commits to keep applying cleanly on master
<[ARP]hoijui_g5> yeah that
<Kloot> eh, you mean on the release branch?
<Kloot> (it's master that starts to diverge)
<[ARP]hoijui_g5> i also did not know that you check all my formatting commits
<[RoX]Tobi> it is only to make it easy to skim through commits and know quickly which ones are easier/harder / more/less important to process
<[RoX]Tobi> (process for any purpose, whether it be cherry picking or reviewing or simply keeping up to date with what others are doing)
<Kloot> [ARP]hoijui_g5: I check each and every commit usually
<[ARP]hoijui_g5> ok
<[ARP]hoijui_g5> well.. the idea of the formatting commits is to not have to check them
<[ARP]hoijui_g5> but if you do... yeah...
<[ARP]hoijui_g5> :/
<[ARP]hoijui_g5> so what now..
<Kloot> I know, but iirc atr least two bugs were introduced in such commits, that's why I started skimming those too
<[ARP]hoijui_g5> should we vote on the policy(ies)?
<[ARP]hoijui_g5> yeah true that
<Kloot> so for me, the total number of LOC-to-check is the same
<Kloot> and I thought others did too
<[ARP]hoijui_g5> yeah if you check them, that defeats this pro of course, but there are still the others
<[RoX]Tobi> personally I never check(ed) formatting commits
<zerver> I never checked any commits
<zerver> and I'm happy
<[ARP]hoijui_g5> :D
<zerver> we may need a new addition to git rules
<[ARP]hoijui_g5> sure
<zerver> if someone makes s bugfix or similar, and you dislike the way it is done, dont revert, instead improve the commit
<[ARP]hoijui_g5> improve only makes sense if it needs marginal changes only
<[ARP]hoijui_g5> if you want it totally different, revert is better
<[ARP]hoijui_g5> why woudl you not want revert?
<zerver> because revert --> no bugfix at all
<Kloot> that means when someone commits a hackish fix and no-one feels like cleaniing it up/restructuring it the hack stays
<zerver> this SlowUpdate thing we talked about is a prime example
<zerver> what im saying is, try to improve it, and you will see how easy it is
<zerver> it may not be as easy as you think to write a cleaner solution
<Kloot> yeah I know
<Kloot> but those hacks accumulate
<[ARP]hoijui_g5> yeah
<Kloot> and eventually nothing is easy to clean anymore
<Kloot> spring is already tangled up too much (you change something in part A and code in seemingly unrelated part B breaks)
<Kloot> (good case to catch with unittests)
<zerver> yeah
<zerver> im just saying i didnt find a better way than SlowUpdate yet, so the bug remains
<zerver> and i don't think that is better than a semi-hackish way
<Kloot> how serious is the bug compared to the level of "entropy" the solution introduces?
<[ARP]hoijui_g5> what? .. i explaiend a way to you in github comments
<[ARP]hoijui_g5> you said you though of it yourself already
<zerver> it didnt work out, the code produced was spaghetti
<zerver> too much of the code in slowupdate need to be executed in this case i guess, so break out is a no go
<zerver> ie, i could break it out, but would end up with something that is almost a copy of SlowUpdate
<[ARP]hoijui_g5> even if it is the qhole of slow update, it woudl be better then what you had
<[ARP]hoijui_g5> whole*
<[ARP]hoijui_g5> conceptually clean
<[ARP]hoijui_g5> -er
<zerver> mmmkay
<zerver> i will do that then
<[ARP]hoijui_g5> so... for git rules... what is the outcome now?
<[ARP]hoijui_g5> hmm maybe we herewith define them as strict rules, not as sort of recommendations?
<zerver> how many days on bread and water if violated?
<Kloot> and you still need to check commits all the time for violations
<[ARP]hoijui_g5> so.. you do not want to follow that rule (splitting)?
<Kloot> I'll respect the majority vote, but just know strict regulations don't work when people are not payed/under contract
<[ARP]hoijui_g5> mmm
<zerver> BTW Kloot, I very much agree with you that too strict regulations don't work in volunteer projects like this one
<zerver> (if you want a boss yelling at you, go and get a paid job instead)
<[RoX]Tobi> it's a matter of mutual benefit.. it's a small investment which can save others way more time, allowing them to be more productive, which is good for the project as a whole
<zerver> indeed, and im not saying break the rules on purpose, but shit happens
<zerver> i much rather have 3 good bugfixes in one commit than no bugfix at all
<[RoX]Tobi> yeah, no need to punish ppl for that or so, but it's good to bring it up so that everyone can improve
<[ARP]hoijui_g5> you dont accidentially put 3 bug fixes into one commit ;-)
<zerver> u can, but that would be rare
<[RoX]Tobi> (IMO that is actually one of the reasonsn to skim / review commits)
<[ARP]hoijui_g5> saying it happens accidentially... really.. that is just lieing
<[ARP]hoijui_g5> its like having accidential sex
<zerver> :P
<zerver> not they way I see it
<zerver> you start fixing bug 1, then by chance discover the somewhat related bug 2...
<abma_irc> nobody here is perfect...
<zerver> or even more likelly, when fixing bug 1, you come across some ugly code
<zerver> and your fingers are twitching, eager to fix it
<[ARP]hoijui_g5> we all know how it happens, there is still nothing accidential there
<[ARP]hoijui_g5> if you want, i can explain again what i do to separate stuff afterwards
<[ARP]hoijui_g5> i have a script called gfilter
<[ARP]hoijui_g5> i call it on a file, and it then opens the two versions of the file in meld (my fav diff editor)
<[ARP]hoijui_g5> the one with all current changes, and the unchanged one
<[ARP]hoijui_g5> then you just do a few clicks (usually, the bug fix parts is small)
<[ARP]hoijui_g5> then save
<[ARP]hoijui_g5> and commit wiht git gui
<[ARP]hoijui_g5> if the separation is hard, becuase both changesets are large, you should not have started to mix them in the first place, or live with it taking a bit longer to separate
<[RoX]Tobi> in git gui you can also right click -> stage hunk / stage line as long as they are at least a little bit separated
<zerver> I wish my fingers were twitching to do any of those procedures
<[ARP]hoijui_g5> DOH! i did not know Tobi :D
<zerver> i have occasinally staged chunks though
<[ARP]hoijui_g5> yeah.. in most cases that should be sufficient.. much easier :D
<[RoX]Tobi> it's the number one reason I prefer git gui to git add / git commit on commandline (most ppl I've spoken to about git prefer commandline :))
<[ARP]hoijui_g5> mmm :-)
<[RoX]Tobi> but I haven't yet been able to make sense of this interactive add mode (git add -i or -p IIRC)
<[ARP]hoijui_g5> ahh never heard of that
<[ARP]hoijui_g5> it lets you choose only part of files to stage?
<zerver> i still not figured out what command sequence in git gui that equals "git pull"
<zerver> i read its fetch & merge, but git gui is complicated
<Kloot> pull is shorthand for fetch+merge yes
<zerver> so exactly what menu items in git gui would i chose?
<[ARP]hoijui_g5> i only use it for committing
<[RoX]Tobi> personally I use commandline for clone/pull and branching/merging/complex stuff and use git gui for staging, committing and pushing
<zerver> same here :P
<zerver> makes me think that git gui can be improved
<[ARP]hoijui_g5> yeah, stageing and committing here
<[ARP]hoijui_g5> they should do something about the windows eol problem
<[RoX]Tobi> that's biggest problem yeah
<[ARP]hoijui_g5> after that, i guess GUI tool support would imprive muhc faster
<[ARP]hoijui_g5> as that is mainly something that windows users want
<[ARP]hoijui_g5> i would also not want to work on that if the base tool had suhc a major flaw

Conclusions:
Split commits are preferred and Git Gui could be better



=== name-value pair properties for objects (eg in unit, feature, weaponDef)? ===
<[ARP]hoijui_g5> ok then that next topic...
<[ARP]hoijui_g5> it is something that came to me in half delirium.. is probably totally unrealizable in C++
<[ARP]hoijui_g5> the idea:
<[ARP]hoijui_g5> as we have these objects (feature, unit, weapon) and the properties exist in different .. ways
<[ARP]hoijui_g5> like.. some in the class Unit as members
<[ARP]hoijui_g5> there is also a properties map in some classes
<[ARP]hoijui_g5> some are in struct unitDef as member
<[ARP]hoijui_g5> some exist only in lua
<[ARP]hoijui_g5> and i wondered if there is a way to unify them
<[ARP]hoijui_g5> most simple idea:
<[ARP]hoijui_g5> .. is alreayd quite ugly and complex :D
<[ARP]hoijui_g5> the actual values are stored in arrays (one per each basic type: float, int, bool,...)
<zerver> should work, unless access is performance critical
<[LCC]jK> there was already such a discussion with saving all those things in a std::map
<[ARP]hoijui_g5> yeah.. if performance is no problem, it is easier
<[LCC]jK> but it was dismissed because it is too performance critical code
<[ARP]hoijui_g5> i though of it liek this:
<[ARP]hoijui_g5> properties have a name(string), but you never access them directly with that, but through an index
<[ARP]hoijui_g5> you can request the index for a property
<[LCC]jK> and then you need to buffer those ids -> just clutters the whole code
<[ARP]hoijui_g5> then.. eg store that index in a static var or something
<[ARP]hoijui_g5> yeah
<[ARP]hoijui_g5> it owuld be ugly... i guess it would work relatively nice in languages like ruby
<abma_irc> re :)
<[ARP]hoijui_g5> lets just forget it :D
<[ARP]hoijui_g5> hey abma! :-)

Conclusions:
Object properties stored in any non O(1) data structure would be too slow



=== plan for big refactors (regarding branches - how to not messup them) ===
<[ARP]hoijui_g5> so.. when we start doign big refactors
<[ARP]hoijui_g5> what would we do to not "loose" branches
<[ARP]hoijui_g5> whether our own or those of others
<[ARP]hoijui_g5> maybe just... announce when these things happen, and maybe skim through github to see who has branches
<[ARP]hoijui_g5> and tell them to merge master in frequently during the next month or something
<[LCC]jK> what is so critical?
<[ARP]hoijui_g5> mm... what do you mean?
<[ARP]hoijui_g5> i mean...
<[ARP]hoijui_g5> when there is lots of heavy changes comming up
<[ARP]hoijui_g5> adn people see like 200 files wiht conflicts when trying to merge, they often give it up totally
<[ARP]hoijui_g5> even some spring devs seem to fear merge conflicts, so no wonder
<[ARP]hoijui_g5> it sounds really bad if you have not yet seen t often
<[LCC]jK> you want to make "master" for releases only, and add a new branch "develop", or what do you mean?
<[ARP]hoijui_g5> and.. when they would merge often, that problem would seem.. smaller
<[ARP]hoijui_g5> i want to do that yes, but that is unrelated to this topic
<[ARP]hoijui_g5> i just mean... as we plan to restructure stuff
<[ARP]hoijui_g5> or maybe .. as a general rule.. we should maybe ... tell people to merge more often
<[ARP]hoijui_g5> or inform them of upcomming changes.. and ask if they want their branches merged in before that
<[ARP]hoijui_g5> maybe announce on github
<[ARP]hoijui_g5> in a way so everyone who has a fork of spring and uses RSS feed sees it
<[ARP]hoijui_g5> mmm nothign really to discuss i guess
<zerver> i have no objections
<[ARP]hoijui_g5> :D
<[ARP]hoijui_g5> ok
<[RoX]Tobi> I think it is fine if refactorer use common sense and take quick look on github, forums and/or etherpad to check whether there are any branches with major changes in the area he wants to refactor
<[ARP]hoijui_g5> hmm.. yeah also an option
<[ARP]hoijui_g5> more.. minimal
<[RoX]Tobi> and brancher takes has his own responsibility to merge often
<[ARP]hoijui_g5> optimized
<[ARP]hoijui_g5> yeah true
<[RoX]Tobi> I think there's no need to formalize this, just be pragmatic and go ahead :-)
<[ARP]hoijui_g5> maybe just tell them once, as a general rule
<[ARP]hoijui_g5> i remember that one of you told me to merge master in from time to time, when working on my ai interface branch (still svn back then)
<[ARP]hoijui_g5> i did not even think on that
<[ARP]hoijui_g5> yeah ok.. maybe i will make a forum post or on github, maybe not.. nothing more to be done
<[ARP]hoijui_g5> that was last thing on the list
<[ARP]hoijui_g5> anyone has somethign else?
<Kloot> when is 82.7 planned?
<[ARP]hoijui_g5> i need koshi to repack rapid first
<[ARP]hoijui_g5> and... as it is now in the release branch, the build stance stuff is worse then before
<abma_irc> hm, whats wrong there?
<Kloot> with the std::max() removed?
<[ARP]hoijui_g5> what happens not too unfrequently (muhc mroe often then the builder frozen problem, for me):
<zerver> it has gotten worse?
<[ARP]hoijui_g5> con is told to build a structure, but has to move away to be able ot build it
<[ARP]hoijui_g5> it moves, stops, but is still in the way
<[ARP]hoijui_g5> then tries to build anyway, and fails, and the build order is discarged
<zerver> yeah, that is old bug or issue
<[ARP]hoijui_g5> its something else, but it is worse in my eyes
<zerver> not related to the buildstance/ slowupdate thing
<[ARP]hoijui_g5> mmm ok.. felt like it happens more often.. but yeah.. my felign is not worth much
<[ARP]hoijui_g5> ok
<[ARP]hoijui_g5> some more test games on release branch woudl be nice
<[ARP]hoijui_g5> i had quite some with AI, and godde did his pathing tests with earlier versions
<Kloot> only godde did any serious pathing tests though (and I already knew about most of the issues he reported)
<Kloot> you basically can't get volunteers for largescale tests
<[LCC]jK> Licho said ZKLobby is ready for multi-engine version support
<[LCC]jK> will ask him if it really is
<[LCC]jK> *multi-version engine support

Conclusions:
Please be careful and inform other devs when making big changes in master
0 x

abma
Spring Developer
Posts: 3554
Joined: 01 Jun 2009, 00:08

Re: Dev meeting minutes 2010-12-20

Post by abma » 21 Dec 2010, 01:36

i've made a list of all meetings with links to the corresponding phpbb-thread: http://springrts.com/wiki/Development:Minutes

(maybe update this yearly)
0 x

User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14599
Joined: 17 Nov 2005, 02:43

Re: Dev meeting minutes 2010-12-20

Post by Forboding Angel » 21 Dec 2010, 03:19

<Kloot> you basically can't get volunteers for largescale tests
This is bs. I have never once been asked to help test something other than when tobi pm'd me over a year ago asking me to help test a new spring version. Volunteers will pop up more frequently if you bother to ask.
0 x

User avatar
smoth
Posts: 22298
Joined: 13 Jan 2005, 00:46

Re: Dev meeting minutes 2010-12-20

Post by smoth » 21 Dec 2010, 03:34

I test a LOT :'(
0 x

User avatar
Licho
Zero-K Developer
Posts: 3803
Joined: 19 May 2006, 19:13

Re: Dev meeting minutes 2010-12-20

Post by Licho » 21 Dec 2010, 04:52

I asked Aegis some time ago to add custom parameter into battles so lobby knows engine version of game without nasty hacks.
I guess I will just hack it using title..

I will try to prepare some autohosts with newer engine version. Just tell me which one you want to test.

For lobby to be able to download the version, it must be in springrts.com/dl in zip or exe (installer) form.
0 x

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

Re: Dev meeting minutes 2010-12-20

Post by hoijui » 21 Dec 2010, 10:54

conclusions revised:
Some source files will be ripped out from the repo and replaced with libs
For 7z, minizip and md5, we will depend on dynamic libs supplied by the distribution/OS/mingwlibs, instead of static libs compiled from code in our repo.
Unit testing is not prohibited, if anyone likes to do it, go ahead
Primary choice is the boost framework, but if the first guy writing a test uses something else, it will not be categorically neglected.
Tests should be in a separate dir structure, resembling the one under rts/.
Split commits are preferred and Git Gui could be better
The way you write it, it sounds like it was treated so far.
We decided that it is an important rule. you have to keep it in mind with every commit you do, and follow it. it is always possible.
Object properties stored in any non O(1) data structure would be too slow
My approach would have used an O(1) structure. Its manco is ugliness (lots of extra code to fetch simple properties only).
Please be careful and inform other devs when making big changes in master
... which apart from engine devs, may also include contributors. if you see on github, that they have changes in the same area of the code you will be changing heavily, inform them.


@forb & smoth
What Kloot said there is not bullshit.
It is about as much work as organizing a tourney, just that it is harder to get players because of several reasons:
  • They do not have the right engine version installed already.
  • They might have to compile it themselfs (non-windows)
  • "The installer will mess up my whole OS!"
  • "I do not want to test stuff that might not get released as it is!"
but lets just say: this evening! with whatever will be current engine test version by then (just have to add minor stuff):
http://springrts.com/phpbb/viewtopic.php?f=12&t=24406
join lobby channel: #playtest

@Licho
springrts.com/dl/ is not a good place, if you also want to be able to get test versions, as they will never be there.
could you add support for getting them from http://springrts.com/dl/buildbot/default/?
The optimum would be, if the current release manager (or any other spring dev) could go to the autohost and issue a command like:

Code: Select all

!use-engine-version master/0.82.3-1081-g9c7eecb
Which would mean, get/use the engine under http://springrts.com/dl/buildbot/defaul ... 1-g9c7eecb[/b]/.

We should have a meeting (lobby-client and -server devs plus that austrian guy, new... something) to discuss/agree upon how to extend the protocol.


If the release manager could do all preparation by himself, and then users and game-devs would just have a few test games themselfs in the evening, without any engine dev having to do organization...
that i would see as a big improvement.
is it possible to have an RSS feed from a single forum thread? or should i publish engine test versions somewhere else, where this is possible?
0 x

User avatar
Licho
Zero-K Developer
Posts: 3803
Joined: 19 May 2006, 19:13

Re: Dev meeting minutes 2010-12-20

Post by Licho » 21 Dec 2010, 14:10

If you can join older autohost with newer spring then all should work.

Biggest annoynce is the UBER ANNOYING CONTENT HASHES DEPENDING ON BASECONTENT ETC.

Also stupid dedicated server must know hashes or clients wont join.

Please disable hash checks if dedicated server has hash 0 for map and mod.
(In case of hash 0 disable initial content hash checks).

That way one autohost will be able to host different spring versions without me reinstalling it, restarting it, hashing all my maps and mods and sending those data to autohost so it knows hashes for maps and mods under its new spring version.
0 x

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

Re: Dev meeting minutes 2010-12-20

Post by AF » 21 Dec 2010, 14:39

Are we running under uberserver or Hoijuis TASServer in the lobby atm?
0 x

User avatar
Licho
Zero-K Developer
Posts: 3803
Joined: 19 May 2006, 19:13

Re: Dev meeting minutes 2010-12-20

Post by Licho » 21 Dec 2010, 15:53

Its uberserver.

Code is fairly easy to modify.
0 x

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

Re: Dev meeting minutes 2010-12-20

Post by hoijui » 21 Dec 2010, 16:36

when the protocol changes, the main issue is not changing code, but finding a nice solution everyone agrees with, getting everyone to change his code, and coordinate the change to the new system.
That's why we need a meeting.

It possibly could be done somehow, using hacks, but i hate using ugly, fast hacks, just for the sake of it being faster. it is especially bad for a protocol, cause once you have the hack, nobody will be willing to implement a clean solution. "why change?? it already works?!"

hashes:
yeah, we need support for individual hashes.

the lobby protocol is now here:
https://github.com/spring/LobbyProtocol
feel free to fork it and create branches, so we can compare and discuss them.

edit:
i have a branch in the workings (local only so far), resembling what we discussed once.
0 x

User avatar
Licho
Zero-K Developer
Posts: 3803
Joined: 19 May 2006, 19:13

Re: Dev meeting minutes 2010-12-20

Post by Licho » 21 Dec 2010, 16:42

I will just use title for now because - being compulsive coder- I want to set it up today.
0 x

User avatar
aegis
Posts: 2456
Joined: 11 Jul 2007, 17:47

Re: Dev meeting minutes 2010-12-20

Post by aegis » 22 Dec 2010, 01:16

Licho wrote:Its uberserver.

Code is fairly easy to modify.
*too* easy, apparently <_<

and I have a way I wanted to do it, social stuff won't happen for another couple of hours tonight so maybe I'll hammer out the new battle format now
0 x

User avatar
Licho
Zero-K Developer
Posts: 3803
Joined: 19 May 2006, 19:13

Re: Dev meeting minutes 2010-12-20

Post by Licho » 22 Dec 2010, 01:57

I released new version of Zero-K lobby which supports that multi-engines.

To make it download and use different engine than server suggests, just start battle title with
[engineXXXX] where xxxx is version - like
"[engine0.82.6.1-45-g79c95f5] some title"

It gets those versions from buildbot folder directly now.
0 x

User avatar
Licho
Zero-K Developer
Posts: 3803
Joined: 19 May 2006, 19:13

Re: Dev meeting minutes 2010-12-20

Post by Licho » 22 Dec 2010, 04:17

I setup autohost [url=spring://http://@join_player:Iridium1]Iridum1[/url] running 0.82.3-1086-gf318f6e

(You can use !spawn command to make it host other mods for testing)

Zero-K lobby users can simply join and play there.

If you need to host different verison let me know (or if you implement this http://springrts.com/mantis/view.php?id=2268 my assistence wont be needed).
Last edited by Licho on 22 Dec 2010, 04:19, edited 1 time in total.
0 x

User avatar
Johannes
Posts: 1265
Joined: 17 Sep 2010, 15:49

Re: Dev meeting minutes 2010-12-20

Post by Johannes » 22 Dec 2010, 04:19

zerver wrote: <Kloot> only godde did any serious pathing tests though (and I already knew about most of the issues he reported)
<Kloot> you basically can't get volunteers for largescale tests
That's why it feels like a waste to test (or mostly to report, alot of people do test stuff a lot in any case) things, there's no way to know what you already know and what would be helpful when there never was any request, much less a properly detailed one, to do anything.
0 x

User avatar
MidKnight
Posts: 2650
Joined: 10 Sep 2008, 03:11

Re: Dev meeting minutes 2010-12-20

Post by MidKnight » 22 Dec 2010, 05:38

If anybody's been using the new firefox, their testing approach is top-notch!

If you haven't: The browser pops up a little bubble asking you to participate in a study. If you accept, it collects usage information for about a week and submits it to Mozilla (only after asking you, though). You can also see your info and the general study results in nice, pretty graph format, which is a great motivator to participate. You can also suggest future studies.

Something similar would probably serve out interests well. We could have the lobby ask you, and if you accept, it downloads the test engine via rapid, instructs you on what to do, runs spring for you, collects information afterward, and sends it all, plus your infolog, to the server, where it gets compiled into readable results.

...How does that sound?
0 x

User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Dev meeting minutes 2010-12-20

Post by knorke » 22 Dec 2010, 08:55

Sounds like a lot of work.
Of course if somebody wants to do it...
I would rather like to see other things fixed, ie I installed a master version as "portable" but it still changed settings in my "play online"-install.
That is not motivating to try test versions.
0 x

User avatar
Licho
Zero-K Developer
Posts: 3803
Joined: 19 May 2006, 19:13

Re: Dev meeting minutes 2010-12-20

Post by Licho » 22 Dec 2010, 13:26

Knorke you don't have to manually install anything, you are using zkl, just join da game.

Only problem is it actually usesportable installer on the background and this installer by default does things like installing archivemover. But thats really minor.
0 x

Kloot
Spring Developer
Posts: 1865
Joined: 08 Oct 2006, 16:58

Re: Dev meeting minutes 2010-12-20

Post by Kloot » 22 Dec 2010, 13:43

Johannes wrote: That's why it feels like a waste to test (or mostly to report, alot of people do test stuff a lot in any case) things, there's no way to know what you already know and what would be helpful when there never was any request, much less a properly detailed one, to do anything.
Seriously, how many active braincells does it take to conclude what a thread named "ENGINE TESTING" with a link to all changes made since the apparently much-maligned 0.82.6 release is for? Do you really depend on us to spell everything out for you, or can you spare some neurons and deduce that a description like "fix units-stuck-behind-terrain" doesn't refer to either issue Y or Z when everyone and their mother is complaining about issue X=pathing? Don't you think that maybe, just maybe, the request to "test stuff" (namely that which the changes indicate) is posed there implicitly? The sooner you gain those psychic powers and realize this, the quicker you'll be able go back to your 8v8 BADSD world with functionality X restored.

Furthermore, the critical difference between Godde and you is that Godde:
  • managed to figure all this out on his own and provided direct helpful feedback on the fixes that *were* committed for specific (pathing) problems reported by him and others, which is never a waste
  • did not spam hundreds of useless replies across the forum with subtle and less subtle embedded remarks about how much he thinks pathfinding sucks/is broken and why we are morons for not doing anything about it, thereby *actually* wasting his own time and ours
Give nothing, get nothing.
Last edited by Kloot on 02 Jan 2011, 22:25, edited 1 time in total.
0 x

User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14599
Joined: 17 Nov 2005, 02:43

Re: Dev meeting minutes 2010-12-20

Post by Forboding Angel » 22 Dec 2010, 22:05

Kloot wrote: Seriously, how many active braincells does it take to conclude what a thread named "ENGINE TESTING" with a link to all changes made since the apparently much-maligned 0.82.6 release is for?
When that thread got locked for reply, I lost interest. If it were an active discussion, it would have been interesting and I might have helped, but all I see in that thread are a bunch of disconnected git revision numbers that don't tell me a goddman thing at all chronologically.

Here is evo test revision: 9349828734,23.239823345t.34923823.2349, no go test and tell me something useful.

The part that just made me give up was when I realized that they weren't chronological, and in certain versions bugs that had been fixed were absent in other versions, etc etc. If I want a mindfuck, I'll go watch goatse. Spring? Not so much.
0 x

Post Reply

Return to “Meeting Minutes”