Dev meeting minutes 2011-10-03

Dev meeting minutes 2011-10-03

Minutes of the meetings between Spring developers are archived here.
Post Reply
User avatar
hoijui
Former Engine Dev
Posts: 4344
Joined: 22 Sep 2007, 09:51

Dev meeting minutes 2011-10-03

Post by hoijui »

Date: 4-10-2011
Present: zerver, jK, hoijui, Tobi

Agenda
  • Welcome
  • Choose a branching/versioning model
  • x-axis inversion in LocalModelPiece?
  • can scripts in tools/scripts/* be removed?
_______________________________________________________________________________


Welcome
<hoijui> next?
<hoijui> :D
<hoijui> i will do minutes
<hoijui> sorry... didnt do it since long already
<hoijui> are you here?
<zerver> yep
<hoijui> mmm ok...
<hoijui> guess we'll just start
<zerver> yea


Choose a branching/versioning model
<hoijui> http://springrts.com/phpbb/viewtopic.ph ... 46#p501746
<hoijui> this post and older ones are to be considered
<hoijui> i like 11 the most, but am not strong about that
<hoijui> (means the biggest change to current)
<zerver> I typically always use dates as version numbers
<zerver> Spring 2011.10.03
<jK> calling next release 1.0 is very optimistic
<zerver> But for Spring, we need the sync compatibility and stuff in the version number, so a date is maybe not a good idea
<hoijui> :P
<hoijui> i though we agree that versions are just numbers
<hoijui> 1.0 does not impy anything abotu stability
<zerver> :P
<jK> for the user it implies things
<hoijui> we could use 20111
<hoijui> well
<hoijui> SL also uses versions greater then 1
<hoijui> there was no problem there
<jK> like ut99 ut2k3 ...? still such would cause if there are more than 1 release per year
<hoijui> really cant see hwo this should be a problem in practice
<jK> SL started with >1
<hoijui> also ok with me
<hoijui> not that it makes sense but well :D
<zerver> Maybe swap out the 0.83 with 2011?
<zerver> 2011.1.2
<zerver> Or use just 11
<zerver> 1
<zerver> 11.2.1
<zerver> Or 0.11, to not give too high expectations :P
<hoijui> mayor: 11 / patchset: 2 / dev-indicator: 1
<hoijui> :P
<hoijui> if 11 stand for hte year, then we dont have to add a 0.
<hoijui> stands*
<zerver> +1
<hoijui> i am fine wiht that
<jK> dates make it more complexe to read
<hoijui> RC11 with the initial 1 replaced by 11
<jK> e.g. it's harder to compare 2011.7.14 with 2012.1.27 than 0.82.7.1 with 0.83.1.0
<hoijui> versions for users would look like this:
<hoijui> 11.0
<hoijui> 11.1
<hoijui> 11.2
<hoijui> 12.0
<hoijui> ahh doh.
<jK> and what if we have a release at the end of the year and a bugfix release happens in the next?
<hoijui> ok yeah .. would need one more number
<zerver> yeah, need 3 numbers
<hoijui> then i dont like it
<hoijui> prefer RC11
<zerver> If the bugfix is in the year after, keep the previous years number
<jK> lol
<hoijui> we could start with an arbitrary nummber, if 1 would really be a problem.. evne though it is not, in my eyes
<jK> users either expect much more stability or extreme new cool features in a 1.0 release
<hoijui> ..so what?
<zerver> and we have only more bugs to offer them :P
<hoijui> shoudl we adabt to the most stupid of our users now?
<jK> not fulfilling the users expectations is bad
<hoijui> so.. i gonna ask yan what devs should be doing, and you gonna do that, k? jk?
<hoijui> tribulex maybe
<hoijui> or one of thos DSD only 12 year old newbs
<hoijui> which probably dont even know the version of spring they are playing
<hoijui> maybe we should add an additionl 0. at the start, to make up for the bugs we added
<zerver> :)
<hoijui> we explain the new versioning scheme, and who does not read it, and expects there to be more stability, and is disapointed and mad at us and quits playign all spring games..
<hoijui> ouh yeah.. that is our target audience
<hoijui> the ones we should care about when doign our versioning scheme
<hoijui> [RoX]Tobi, you here too?
<zerver> 1 is fine too, but I'd like some correlation between year an
<zerver> and version
<hoijui> 111?
<hoijui> 11.83
<hoijui> :D
<hoijui> nah thats bad of course
<hoijui> i agree that year would be nice, it woudl make clear the nature of the version not indicating stability to the most stupid even (i guess)
<hoijui> but it woudl add an other dot
<hoijui> would still be one dot less for releases then what we have now
<hoijui> dev tags would have same many dots as patch releases now
<hoijui> so yeah.. still ok with me
<jK> use a..z for minor version?
<jK> hmm may be not a good idea
<zerver> 2011.1a
<jK> hard to parse by lua
<zerver> :)
<zerver> If I make 2 releases in one day, I do 2011.10.03a and 2011.10.03b
<zerver> so I like that idea
<hoijui> we will have no minor versions
<zerver> 2011.1a syncs with 2011.1b
<hoijui> mm.. i se no problem wiht that right now.. loks fine to me too
<hoijui> we could skipt the initial 20
<hoijui> or not.. dont know
<hoijui> is short enough this way already
<jK> neither does date imply if it is a major or minor release
<hoijui> should work for standard version comparison algos
<hoijui> there are no minor releases
<jK> oh and we stop writing bugs because you say so?
<hoijui> is that related?
<jK> obv.
<hoijui> i mena.. you can make minor releases of course
<hoijui> but.. it is not manifested in the version number
<hoijui> no difference from a major one
<jK> <[LCC]jK> neither does date imply if it is a major or minor release
<jK> which is a no go
<jK> users needs to know if the update he downloads is minor or major
<hoijui> stop making up virtual problems please
<hoijui> this is not a problem
<jK> search a mirror ...
<hoijui> minor releases as we had them will not exist, cause of the different branchign model
<hoijui> that is one of the main advantages
<hoijui> much less painfull life for release manager
<hoijui> or generally for releasing
<jK> minor releases are minor releases and have nothing to do with branching model
<jK> a bugfix is a bugfix period
<hoijui> you can wirte "minor release" on the release post and on hte download page
<jK> it makes the life more painfull cause the version number does not imply if it needs bugger modifiactions of maintainer to get it run
<hoijui> a sync relevant bug fix creates a new release
<hoijui> bugger modifiactions of maintainer?
<jK> and there is _non_ sane way to find out if it is majpr/minor with such a naming scheme
<hoijui> dont understand
<jK> game devs needs to adjust their games to the engine
<jK> ?
<hoijui> aehh... game devs have to read the release post?
<hoijui> game devs will know, that if hte last release was yesterday
<hoijui> that it is a minor release?
<hoijui> virtual problem?
<hoijui> check
<jK> oh yeah, they will just know, the same way you know how your brain works because ... it's yours?
<hoijui> no
<hoijui> becuase we wrote "minor release" in the release post
<hoijui> whcih they ALWAYS have to read anyway
<hoijui> and because if they are sane, they know that we can not make 1000 heavy changes in a day?
<jK> oh you want to force them ... good idea ...
<jK> and yeah, nice if you find a unknown number in a bug report infolog and need to spend 5mins on finiding if it is minor/major and how it correlates to the other releases
<hoijui> i say we go next
<hoijui> without Tobi, and jk just makign up one virtual problem after the other, this is totally useless
<jK> next 2 items need tobi/tvo
<jK> *erm tobi/kloot
<hoijui> ah :/
<hoijui> k
<hoijui> nice! :D
<hoijui> meeting doen
<hoijui> Tobi seems to have awfully lots of real life distraction lately...
<hoijui> ;-)
<Tobi> what am i needed for?
<Tobi> sorry i am afk'ish I often start doing other stuff when meeting hasn't started in the first 10 min
<hoijui> ok :-)
<zerver> np, same here
<hoijui> all 3 points of the agenda
<hoijui> we ended the first
<hoijui> cause you were not around
<hoijui> but now should go on there
<Tobi> can you pm me link to the etherpad with agenda? seems I lost the link
<hoijui> zerver suggested version 2011.0a
<hoijui> done
<Tobi> so I need to say something about this version number stuff?
<hoijui> a->b->c->... for patchsets
<hoijui> yeah :S
<Tobi> as for branching model itself the RCs came a bit too fast for me to follow
<hoijui> ok.. can just look at the last two then, i guess
<Tobi> for version numbers, why do we want a change?
<hoijui> compared to RC3?
<hoijui> or to release
<Tobi> no I mean, why suddenly 2011.0a or so?
<hoijui> :D
<hoijui> ok i guess you have to go through the RCs then
<hoijui> 4+
<hoijui> from 4 upwards i mean
<hoijui> or maybe in short.. i try:
<hoijui> we got rid of the + and -
<hoijui> so it is easier to compare versions
<Tobi> oh, with one extra version?
<Tobi> *version number
<hoijui> the branch name wasremoved from the version (and added at the end) so the version can always be used in git directly, for reference
<hoijui> yes
<hoijui> exactly
<hoijui> wiht the extra version, we ended up with a lot of dots
<hoijui> so we tried to git rid of some
<hoijui> jk, what woudl you say to:
<hoijui> 2011.10a
<hoijui> 2011.20a
<hoijui> 2011.21a
<hoijui> first to mayor, second minor release?
<hoijui> major*
<jK> you mean 2011.10b = 10 major b minor?
<hoijui> b is patch
<hoijui> first patch release
<hoijui> as in, not sync relevant
<jK> 2011 as major doesn't work when there are 2 releases in a year (and we still target 2 of those)
<hoijui> no
<hoijui> i mean..
<hoijui> 2011.1 is major
<hoijui> aehm.. dont know how to explain.. it seems obvious from the example
<hoijui> there is no hard distinction betwen major and minor (using a dot)
<hoijui> but it is still obvious to humans
<jK> still I prefer something that is compatible with current lua version parsers
<hoijui> standard lua algorithms for parsing versions?
<hoijui> or algos used in spring?
<hoijui> using letters in versions is quite standard
<jK> functions in lua code
<Tobi> which problem is adding the year supposed to solve?
<hoijui> jk does not like using 1
<hoijui> becuase it implies a much more stable release :P
<Tobi> could also s/0.83/83/
<hoijui> and using the year makes clear this number is not stability related
<Tobi> as that's practically what it is anyway
<zerver> it does not solve anything really, but IF we are going to change 0.83 into something else, I just prefer a number that actually means something
<hoijui> 1, 2011, 11 and 83 would all work for me
<hoijui> but i agree wiht zerver
<hoijui> using 2011 or 11 kind of adds a little information and costs us nothing really
<hoijui> (except that we need an other number for more then one release per year)
<Tobi> to get things straight: we want at least 3 components: sync-ok/api-ok, sync-breaks/api-ok, sync-breaks/api-breaks, right?
<hoijui> well...
<hoijui> if you realyl want that, then the branching model does nto work well for it
<hoijui> it means we can not introduce api breaking changes in develop
<hoijui> as long as we plan to have an other non-api brekaing release
<hoijui> which is bad of course
<Tobi> in the branching model they are equivalent to hotfix / new release from existing release branch / new release branch, I'd say?
<hoijui> "new release from existing release branch" is not part of the new branchign model
<Tobi> hmm
<hoijui> it would be quite similar to the old model again
<hoijui> maybe it would work, but minimum requirement woudl be, to make all non-api brekaing changes in the release branch
<Tobi> not necessarily all
<hoijui> yeah.. all that shoudl be in the release
<Tobi> I don't want the version number to mean "this version includes *all* non-api breaking changes that have been made before this point in time"
<Tobi> it only has to mean "this version includes *no* api breaking changes"
<hoijui> mm, i also did not understand it that way
<hoijui> just wnated to say, it gets uglier again
<hoijui> and honestly.. will not be doen in practice
<Tobi> as in, api breaking changes will be put in release branch?
<Tobi> or as in, cherry picking will happen?
<hoijui> :D
<hoijui> second
<Tobi> hmm that is true yeah
<Tobi> as it will be unclear whether a new minor release will be made or not
<Tobi> I'm starting to think we have too many APIs anyway to have one version number designate a change in any of them
<hoijui> yeah .. i did nto even think of that ;-) but that makes it more likely even, yes
<hoijui> yeah also true
<hoijui> though.. making more versions for them would not solve any of the problems we are having here.. would it?
<hoijui> or you want to externalize them?
<Tobi> so then I would suggest to forget about the separation between sync-breaking and api-breaking: any normal release may break API or sync, any hotfix release may break neither API nor sync
<hoijui> +1
<Tobi> and put in release post some per-API version number, or otherwise a quick notice on whether it changed or not
<hoijui> it coudl be done in the release version tag description, in theory
<Tobi> i.e., unitsync API: unchanged, LuaSyncedRead : changed this and this, LuaSyncedCtrl : no changes, etc.
<hoijui> from there it coudl be read and included in additional version string
<Tobi> I think it will be too much information
<Tobi> and at what granularity do you want to put it there
<hoijui> yeah.. from that sample.. true
<Tobi> you can't realistically put the whole part of changelog that relates to any API in the additional version string
<hoijui> yes we can! :D ;-) yeah no.. true
<hoijui> what about only putting it in the tag description?
<hoijui> it woudl be a good spot for reference
<Tobi> you could put it there, but I don't know where that is visible
<hoijui> yeah not in many places
<hoijui> in gitk it is, or in git log i think..
<Tobi> anyway, that means we need only 2 components of version number for real releases: regular.hotfix
<hoijui> of course it woudl have to be in the release post aswell
<hoijui> yeah :-)
<hoijui> and i guess we will not use letters, casue of Lua stuff
<Tobi> I suppose the question then remains how to version development builds
<hoijui> adding a ".1" at the end seems a godo solution to me
<hoijui> it shoudl work well with comparison algos
<hoijui> evne lua i guess
<Tobi> so previous-regular.0.1 ?
<hoijui> yes
<hoijui> aehm
<hoijui> not sure what you mean with previous-regular
<Tobi> I mean that, after 0.83, dev builds are 0.83.0.1
<Tobi> err bad example
<Tobi> after 83, dev builds are 83.0.1
<hoijui> yeah
<hoijui> it is RC11 with the initial 1 replaced by 83
<Tobi> seems so yeah
<hoijui> we wont have a 1.0.1 :*(
<Tobi> I think odd/even is better though: then it is clearer there is no compat with release (also in checks in code)
<hoijui> better for what?
<hoijui> dev/release version difference?
<Tobi> yes, checks for compat using version number will always return false between development and release builds
<hoijui> ahh i see, that is why we have the branch name in the version :D
<hoijui> the problem wiht odd/even is..
<Tobi> yeah, that is great for humans
<Tobi> not sure which code needs to start checking that too then
<hoijui> when you have a hotfix, it would overwrite the tag in the dev branch
<hoijui> that is why we re-tag that (hotfix branch merged into develop)
<Tobi> you could still re-tag
<hoijui> but with what?
<hoijui> you already used 84 then
<Tobi> e.g. 84 (release) results in 85 tag in develop; 84.1 (hotfix release) results in retag 85.1 in develop
<Tobi> I don't mind too much about this though
<Tobi> just don't really like those many dimensional version numbers :P
<hoijui> if this really works, i would liek it too..
<hoijui> but i am not so sure yet..
<hoijui> for example
<Tobi> it is not structurally different from RC11
<hoijui> 85 suggests it has all commits of 84.1 at least
<hoijui> but it does not
<Tobi> hm, good point
<Tobi> well I don't mind that much, can live with an extra .1 too
<Tobi> even though this suggests API compatibility with the last release ;-)
<hoijui> mm yeah.. :/
<hoijui> both not good
<Tobi> but since the branch will always have develop or {develop} prepended/appended I don't think that's a real problem
<Tobi> and the commit hash, and commit number since last tag, ...
<Tobi> so release and develop are sufficiently distinguishable
<Tobi> so go for RC11 with 1 replaced by a higher number, to indicate lower quality
<hoijui> hehe :D
<hoijui> well said
<hoijui> how exactly should we add the branch?
<hoijui> wiht a space at the end?
<Tobi> just see what happens now automatically, and don't change if it works sufficiently well?
<hoijui> not sure what you mean with.. happens automatically
<Tobi> oh right, you're rewriting that functionality basically
<hoijui> yes
<Tobi> keeping it same as it is now will break the least, though
<hoijui> but .. i have enough info now
<Tobi> side note: for super-ultra-major releases, the single number can still be bumped up by an amount larger than 1
<hoijui> mm :-)
<Tobi> e.g. like how we went from 0.67 to 0.70 for the first version that compiled on linux
<hoijui> jk.. zerver.. want to add something?
<Tobi> +ran
<zerver> not really
<hoijui> mm :-) i did not know that
<Tobi> could go from 83 to 90 now with the 3000 commits since 82 :P
<hoijui> :D
<hoijui> maybe better spare the 90 for all the bugs fixed after fail 83 release ;-)
<Tobi> correction, more than 3500 commits
<hoijui> mm :-)
<jK> if lualoadscreen would be finished I would say we could bump to 85, but it's not :<
<hoijui> yeah can do that then :-)
<hoijui> so.. next?
<Tobi> clearly some version number devaluation taking place :)
<jK> oh isn't 83 the first macos build?
<hoijui> indeed!
<hoijui> first one usable as app bundle
<hoijui> which is the most complex thing a normal mac user can handle
<hoijui> or say... the average mac user
<jK> so bump to 85 or 90 ;)
<hoijui> mm..
<zerver> :)
<hoijui> we have 83 on mantis and on the tag (to be changed anyway) already
<Tobi> can we do next points as I want to go in not too much time
<hoijui> and most people expect 83.. but i guess would still be possible
<hoijui> ok

conclusions:
x-axis inversion in LocalModelPiece?
<hoijui> i guess it is related to this: http://springrts.com/mantis/view.php?id=2664
<hoijui> http://springrts.com/phpbb/viewtopic.php?p=501888
<hoijui> (related forum thread)
<Tobi> I suppose it's related to COB coordinates being left handed and Spring coordinates being right handed or so (or vice versa, don't recall)
<jK> https://github.com/spring/spring/blob/e ... l.cpp#L271
<jK> I don't understand why we do a -1* there
<jK> esp. cause it isn't done in the opengl functions
<Tobi> I don't recall either
<jK> it might be needed somehwere in COB, but in that place it looks totally wrong to me
<jK> and cause such bugs as knorke got
<Tobi> ah, probably because GetPiecePos uses GetAbsolutePos, and GetPiecePos is used everywhere as an offset in positive right vector direction
<Tobi> while +x in COB points to left
<hoijui> *insert hitler video where he screms "every -1 in my source code needs to be commented, THIS IS AN ORDER!"*
<Tobi> yeah it sucks it is there, think it is there since forever though
<Tobi> related to COB using different CSYS convention then everything else in Spring
<Tobi> hmm Spring is right handed; then COB was left handed
<jK> k with that info I assume I found the bug
<Tobi> hmm maybe COB is even worse
<Tobi> according to the wiki
<Tobi> Rotations around x-axis and z-axis are left-handed and rotations around the y-axis is right-handed. To comprehend this more easily, positive angles are shown graphically in the following figure:
<jK> yeah, no euler angles
<jK> mah fix is: `GetPiecePos(piece) + unit->pos` replaced with `unit->pos + unit->frontdir * relpos.z + ...` in Explode()
<Tobi> mmm, so actually if I believe the wiki it is right handed except that rotations around x and z axis are in the wrong direction
<jK> still the -1 in LocalModelPiece is a very bad place for something like that
<Tobi> yes, definitely
<Tobi> feel free to try to remove it, don't think that will be easy though :/
<jK> btw in what direction points unit->frightdir when it corrects this?
<jK> isn't it then leftdir?
<jK> -f
<Tobi> AFAIK rightdir is really rightdir, but I can't give a guarantee unfortunately
<Tobi> uurgh no, I'm reading wiki wrong, it is left handed with y reversed after all <_< (if the wiki is correct ...)
<Tobi> shouldn't think about csyses at this time
<Tobi> *rotations around y
<jK> O_O
<jK> so we got up, left, back vectors?
<jK> omg this code is so evil
<Tobi> yes
<jK> as written by satan himself
<Tobi> :P
<Tobi> http://springrts.com/wiki/Animation-CobAnimation
<Tobi> there is some info
<Tobi> also, "The X axis is mirrored compared to BOS/COB scripts, to match the direction of the X axis in Spring world space." in LUS Move
<Tobi> IIRC that makes it consistent in LUS, but the old Spring.* piece APIs still return things in some arbitrary weird coordinate system
<Tobi> IIRC it even differs between all those APIs, some return in piece coordinates, some in unit coordinates, some in world coordinates, and then probably some in one of those with the X axis reversed :P

conclusions:
  • jk got some better understanding, and might be able to fix the 2664 bug with it.

can scripts in tools/scripts/* be removed?
<Tobi> answer to the next point is no
<hoijui> :D
<Tobi> *some* can be removed, probably, yes, but definitely not all
<hoijui> yeah.. i remember we(you) already did a cleanup there, about a year ago or so
<hoijui> guess abma did not know about that

conclusions:
  • nothing to be done with tools/scripts/*
abma
Spring Developer
Posts: 3798
Joined: 01 Jun 2009, 00:08

Re: Dev meeting minutes 2011-10-03

Post by abma »

can scripts in tools/scripts/* be removed?
i still have no internet at home :-/ this point was by me.
for example, these scripts seems to be deprecated/usless (as they are already applied or they don't work any more...):
https://github.com/spring/spring/blob/d ... SClient.sh
https://github.com/spring/spring/blob/d ... s/merge.sh
https://github.com/spring/spring/blob/d ... alFixer.sh
https://github.com/spring/spring/blob/d ... deFixer.sh

and maybe some more.
User avatar
MidKnight
Posts: 2652
Joined: 10 Sep 2008, 03:11

Re: Dev meeting minutes 2011-10-03

Post by MidKnight »

FAIRLIGHT VERSIONING SCHEME IS THE BEST VERSIONING SCHEME! :o
User avatar
Zydox
Lobby Developer
Posts: 453
Joined: 23 May 2006, 13:54

Re: Dev meeting minutes 2011-10-03

Post by Zydox »

More meeting minutes?
User avatar
zwzsg
Kernel Panic Co-Developer
Posts: 7049
Joined: 16 Nov 2004, 13:08

Re: Dev meeting minutes 2011-10-03

Post by zwzsg »

About version numbers:
- The less you keep changing the versioning scheme the better
- The easier to compare version numbers, the better

In particular, it's important for Lua *dgets coded in the past to be able to detect new Spring versions as being new.
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Re: Dev meeting minutes 2011-10-03

Post by AF »

zwzsg wrote:About version numbers:
- The less you keep changing the versioning scheme the better
- The easier to compare version numbers, the better

In particular, it's important for Lua *dgets coded in the past to be able to detect new Spring versions as being new.

Of note, if we use 83 we must use numbers greater than 83 if we ever change it again, keep that in mind, considering we may change versioning system at some point in the future, be it eyars down teh line given unforeseen circumstances
User avatar
MidKnight
Posts: 2652
Joined: 10 Sep 2008, 03:11

Re: Dev meeting minutes 2011-10-03

Post by MidKnight »

I still support the FAIRLIGHT VERSIONING SCHEME!

...That's 2011.1, 2011.2, etc
User avatar
liamdawe
Posts: 120
Joined: 19 Mar 2010, 15:09

Re: Dev meeting minutes 2011-10-03

Post by liamdawe »

MidKnight wrote:I still support the FAIRLIGHT VERSIONING SCHEME!

...That's 2011.1, 2011.2, etc
Same here, much easier to understand as a whole...and it also solves the bigger than 83 problem ;)
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Re: Dev meeting minutes 2011-10-03

Post by AF »

We can always switch from 83 to 27 ( there have been 26 major releases )
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6240
Joined: 29 Apr 2005, 01:14

Re: Dev meeting minutes 2011-10-03

Post by FLOZi »

There's nothing wrong with 83, I just don't understand the reasoning behind dropping the '0.', other than it possibly being extraneous, I feel like the consistency of keeping it would outweigh the neatness of losing it.
Post Reply

Return to “Meeting Minutes”