Dev meeting minutes 2010-05-09

Dev meeting minutes 2010-05-09

Minutes of the meetings between Spring developers are archived here.
Post Reply
Tobi
Spring Developer
Posts: 4598
Joined: 01 Jun 2005, 11:36

Dev meeting minutes 2010-05-09

Post by Tobi » 09 May 2010, 22:04

We had a first meeting with the current active engine developers today. We decided the meeting will be held in private, but the minutes (which is just slightly fixed/structured chat log) will be public. This way we can ensure meeting will stay short and we can incorporate any useful notes from the general public in the next meeting. Also, if you have stuff you think we should discuss feel free to suggests points for the agenda in this thread.
Welcome
<[RoX]Tobi> welcome all
<[RoX]Tobi> I've a small agenda from some points people had
<[ARP]hoijui_g5> i also have a bit
<[ARP]hoijui_g5> ok... so you start

Agenda
<[RoX]Tobi> * Welcome
<[RoX]Tobi> * Meeting minutes
<[RoX]Tobi> * Who's doing what?
<[RoX]Tobi> * How shall we keep track of who's doing what? Just meeting?
<[RoX]Tobi> * Kick off process for next release
<[RoX]Tobi> - Timeline
<[RoX]Tobi> - List of bugs in master (i.e. get people to test & report bugs)
<[RoX]Tobi> - List of unfinished features in master
<[RoX]Tobi> * Next meeting
<[RoX]Tobi> * Anything else? (WVTTK)
<[RoX]Tobi> * End
<[RoX]Tobi> anything to add?
<[CoW]Kloot> looks good
<[ARP]hoijui_g5> * new buildbot
<[ARP]hoijui_g5> * new infolog upload site
<[ARP]hoijui_g5> * current buildbot isntaller problem
<[ARP]hoijui_g5> these are more specific though
<[RoX]Tobi> yes, guess we can address them in short after 'Kick off process..'
<[ARP]hoijui_g5> ok

Meeting minutes
<[RoX]Tobi> so, meeting minutes: with that I mean, shall we publish publicly the logs of the meeting?
<[RoX]Tobi> and also, will we allow arbitrary public to sit in the meeting room
<[LCC]jK> imo yes
<[RoX]Tobi> I say, publish logs yes, arbitrary public, fine if they are quiet :)
<[CoW]Kloot> imo no live public, they can read the logs afterward anyway
<[LCC]jK> perhaps they have some useful opinions too?
<[CoW]Kloot> not on specific dev agenda points
<[LCC]jK> hmm on the other side they can write them in the forum post with the log
<[RoX]Tobi> that's a valid point yeah, but it risks making meetings very long etc.
<[RoX]Tobi> maybe we could put the minutes in forum and allow people to comment
<[LCC]jK> yeah, that sounds as the better way
** zerver joined the channel.
<[RoX]Tobi> welcome zerver
<[LCC]jK> :)
<zerver> thanks, hi
<zerver> fyi im always late
<[RoX]Tobi> we just started with deciding how public meeting will be etc.
<[RoX]Tobi> ok I'll say 15:30 to you next week ;-)
<[RoX]Tobi> maybe we could put the minutes in forum and allow people to comment
<zerver> sounds like a good idea
<zerver> and who writes the minutes?
<[RoX]Tobi> ok then I take this point as decided, we'll put minutes in forum for everyone to read/comment on, but no public will be allowed during meeting
<[RoX]Tobi> any good points in comments can be picked up at the next meeting
<[RoX]Tobi> I would say they can be (slightly cleaned) log of the conversation
<[RoX]Tobi> I can make them now

Who's doing what?
<[RoX]Tobi> ok, then the next point is: Who's doing what?
<[RoX]Tobi> anyone wants to start? :)
<zerver> we need someone to take over where auswasch left
<zerver> manage releases, moderate commits,...
<[RoX]Tobi> yeah we'll talk about that
<[RoX]Tobi> sec I pastebin the agenda I pasted just before you entered
<[ARP]hoijui_g5> i will take over sound
<[RoX]Tobi> now for the immediate moment I just want everyone to know (in global) what everyone is doing
<[ARP]hoijui_g5> in the pureint branch, i am cleaning up the AI interface
<[RoX]Tobi> zerver, agenda: http://pastebin.com/mpjeLuVK
<[ARP]hoijui_g5> no big change there inside the engine for other parts then the interface itsself
<[LCC]jK> I want to improve the shader class (I want to add dynamic recompilation via myShader.SetDefine("shadows",true) )
<[CoW]Kloot> I have no shortterm work pending
<[CoW]Kloot> for the longer term, finish the model rendering rewrite/unification
<[ARP]hoijui_g5> i am also still wokring on the launcher
<[ARP]hoijui_g5> in theory
<[LCC]jK> launcher?
<[ARP]hoijui_g5> and i am maintainign the springheadless branch of hugh perkins
<[ARP]hoijui_g5> Launcher.exe which then calls spring.dll or spring-dedicated.dll or spring-headless.dll
<[ARP]hoijui_g5> there was a thread once
<zerver> i have nothing going on atm
<[RoX]Tobi> I'm not really doing anything atm, I only have a tiny list of small features/bugfixes I still need to go through, and supposedly I'm setting up old-style buildbot again (i.e. build after every commit)
<[ARP]hoijui_g5> Kloot.. as you did your changes in master.. is it now.. kind of finished, what you are doing there? or at least in a state OK for release?
<zerver> but i'm planning a democratic approach to solve the game speed issue which still pisses me off
<[CoW]Kloot> yes, the unfinished parts are just idle code atm
<[ARP]hoijui_g5> ok :-)
<zerver> and i have the long term goal to make MT official release
<[ARP]hoijui_g5> i have the same long term goal for spring headless
<[ARP]hoijui_g5> the problem there is only...
<[ARP]hoijui_g5> if we include this into the default build cycle
<[ARP]hoijui_g5> spring compilation will take two tiems as long as now
<[LCC]jK> Any objections if I remove the ShaderHandler esp. the shader classes?
<[ARP]hoijui_g5> or.. at least 50% longer
<[CoW]Kloot> remove?
<[LCC]jK> dynamic recompilation would make such classes redundant
<zerver> 100% longer if we include spring_mt.dll
<[ARP]hoijui_g5> :D
<[ARP]hoijui_g5> mmm
<[ARP]hoijui_g5> but!
<[ARP]hoijui_g5> if we will have a buildbot that rebuilds every commit
<[LCC]jK> e.g. all terrain render passes would use the same shader just with different #defines
<[CoW]Kloot> you still need to have a class representing a shader and something that holds all currently loaded instances
<[ARP]hoijui_g5> we can just let him do these builds, and devs only build the standard things
<[RoX]Tobi> yeah
<[CoW]Kloot> jk: do you prefer dynamic compilation over creating all needed/possible shader combinations at loadtime?
<[LCC]jK> yeah
<[LCC]jK> cuz you can do things like terrainShader->SetDefine("shadows",true)
<[LCC]jK> instead of having 1000 different shader objects in your class
<[RoX]Tobi> but then still someone would need to cache the different shaders?
<[RoX]Tobi> or is it fast enough to recompile every frame?
<[LCC]jK> this is very important when you combine different paths (e.g. shadows, extratexture, reflection, detail, ...)
<[CoW]Kloot> even with dc you would have a few, and there'd be recompilation costs
<[LCC]jK> it doesn't need to recompile it each frame
<[LCC]jK> it just needs to do once for each set of #defines
<[RoX]Tobi> so you're caching them?
<[LCC]jK> yup
<[RoX]Tobi> ok
<zerver> we need to establish exactly what is required for an official MT release, maybe you can help with that
<[LCC]jK> fine
<[RoX]Tobi> zerver: is it fine if I put that point on agenda for next time?
<[ARP]hoijui_g5> if we have a launcher, there would be less hurdles for an MT release
<zerver> sure
<[RoX]Tobi> ahh that launcher idea
<[ARP]hoijui_g5> casue you can have MT and normal spring isntalled at the smae time, in the same dir.. and use simple fallback
<[RoX]Tobi> ok
<[ARP]hoijui_g5> i am fine with next too
<[LCC]jK> launcher wouldn't work for linux that easily -> 2 different build paths
<[RoX]Tobi> ok
<[ARP]hoijui_g5> two different build paths?
<[LCC]jK> yeah windows needs to build a dll and linux a binary
<[ARP]hoijui_g5> mm..
<[LCC]jK> duno how much work it is to add this to the cmake script
<[RoX]Tobi> that's all solvable probably, I propose that the technical details be discussed later :)
<[ARP]hoijui_g5> dont knwo what you mean, i see no real difference between windwos and linux
<[ARP]hoijui_g5> the launcer will eb an executable, the rest shared libs
<[LCC]jK> k technicals later
<[ARP]hoijui_g5> cmake stuff is no problem.. am expert there ;-)
<[ARP]hoijui_g5> ok

How shall we keep track of who's doing what? Just meeting?
<[RoX]Tobi> next point: * How shall we keep track of who's doing what? Just meeting?
<zerver> maybe use the wiki to track what everyone is doing?
<zerver> at least this prevents collisions or double work
<[ARP]hoijui_g5> the optimal thing woudl be, if we do not have to do anythign extra
<[ARP]hoijui_g5> like.. if we all commit our work on our spring forks
<[ARP]hoijui_g5> and all of us listen to the toehrs RSS feeds
<[LCC]jK> 2 req. for me -> it needs to fit on one screen page and it shouldn't need any login (or it should cache it via cookies)
<[LCC]jK> so it can be part of my opera session
<[LCC]jK> wiki might not fit on 1 page with the current website layout
<zerver> if we use git you must create some dummy commit already before starting the work
<[RoX]Tobi> moving more towards topic branches seems like a good idea in either case, for the bigger features
<[ARP]hoijui_g5> hmm
<[RoX]Tobi> zerver: nah you can just push branch that's equal to master
<[RoX]Tobi> I think if you watch an entire repository you get things about new branches in your RSS feed too
<[ARP]hoijui_g5> yeah, uisng a meaningfull name
<zerver> ok
<[RoX]Tobi> some other options: mantis, new bug/task/issue tracker
<[RoX]Tobi> [CoW]Kloot, you any opinions on this?
<[RoX]Tobi> or requirements :)
<zerver> clarify plz
<[LCC]jK> making a mantis report is the same work as many things on my bugfix list
<[CoW]Kloot> I would be fine with a private subforum where we have +rw for now
<[CoW]Kloot> it wouldn't be swarming with topics very quickly
<[RoX]Tobi> that's definitely easiest to set up
<[CoW]Kloot> and would give us some more time to evaluate alternatives
<[RoX]Tobi> yeah
<zerver> what would we gain compared to plain mantis?
<[CoW]Kloot> not having to log in in two places :)
<zerver> keep logged in ffs
<[CoW]Kloot> and mantis interface is somewhat unfriendly imo
<[LCC]jK> making a forum post is so slow :/
<[LCC]jK> you need to open 2-3 pages and click 3-5 times for one
<[RoX]Tobi> what about e.g. etherpad?
<[ARP]hoijui_g5> yeah!! :D
<[LCC]jK> does it cache logins?
<[ARP]hoijui_g5> i guess as its web based.. works like everythign else
<[RoX]Tobi> yes
<[RoX]Tobi> it caches logins
<[RoX]Tobi> though there is barely any login, you just need the URL + a nick so people know who you are when you are editting at same time
<[ARP]hoijui_g5> if we want it privately, we would need our own server, right?
<[LCC]jK> does it mean that anyone can edit the document in the free edition?
<[ARP]hoijui_g5> or jsut keep the URL as a secret
<[RoX]Tobi> yeah, only security is through obscurity, by keeping URL as a secret
<[RoX]Tobi> anyway lets pick something to try next week(s) or move on to next topic
<[ARP]hoijui_g5> yeah
<[LCC]jK> free editions seems dead
<[ARP]hoijui_g5> i am pro git/RSS and etherpad
<[ARP]hoijui_g5> the main site yes, but there are others alreayd hosting it
<[RoX]Tobi> piratepad.net has free edition
<[RoX]Tobi> there are also a bunch of others or we could even see if it's easy to install on spring server
<[ARP]hoijui_g5> mm
<[ARP]hoijui_g5> so.. a vote?
<zerver> i'm fine with either, i have no experience with etherpad
<[LCC]jK> yeah, give it a try
<[RoX]Tobi> ok, I'm fine with trying etherpad too
<[RoX]Tobi> [CoW]Kloot, you?
<[CoW]Kloot> do we want one common doc for all devs then? would be a bit chaotic to maintain for day-to-day updates imo
<[ARP]hoijui_g5> you just have your part
<[RoX]Tobi> I suppose each can have his own small list yeah
<[RoX]Tobi> all in the same document
<[ARP]hoijui_g5> mm
<[RoX]Tobi> so you have easy overview, but no conflict when editing
<[RoX]Tobi> ok we'll try etherpad
<[CoW]Kloot> alright, and if its gets too big then it could still be split I suppose
<[RoX]Tobi> yeah or then we could look at other solution

Kick off process for next release
<[RoX]Tobi> * Kick off process for next release
<[RoX]Tobi> - Timeline
<[RoX]Tobi> - List of bugs in master (i.e. get people to test & report bugs)
<[RoX]Tobi> - List of unfinished features in master
<[RoX]Tobi> next point ^^
<[ARP]hoijui_g5> ok
<[ARP]hoijui_g5> i do have some people testing AI stuff, luckyly :D
<[RoX]Tobi> :)
<[ARP]hoijui_g5> but.. i need the installer to work again, which needs cooperation with bibim, or the new buildbot
<[LCC]jK> my shader changes will take 2-4 weeks + 1 week other bugfixes
<[RoX]Tobi> FYI, last tiny release (0.81.2.1) was 16 March
<[RoX]Tobi> last big one 22th of Feb
<[ARP]hoijui_g5> hmm
<[ARP]hoijui_g5> main problem will be the mods
<[ARP]hoijui_g5> how many are there that are really compatible wiht master?
<zerver> mods are incompatible yeah
<[LCC]jK> mods adjust quite fast when there is a RC
<[ARP]hoijui_g5> BA 7.12 eg is not spawning coms
<[ARP]hoijui_g5> :D
<[ARP]hoijui_g5> hmm ok
<zerver> and game keeps going without coms :P
<[RoX]Tobi> so RC can be in 3-5 weeks
<[LCC]jK> /cheat /give armcom ^^
<[ARP]hoijui_g5> :D
<zerver> everyone must promise to give only one com and no krogs :)
<[ARP]hoijui_g5> yeha yeah :D
<[RoX]Tobi> bugs in master: it will be hard to (get people to) find these
<[RoX]Tobi> will work a bit better after RC
<[ARP]hoijui_g5> hmm
<zerver> hoi, did you have any more NULL CUnit crashes in rendering?
<[ARP]hoijui_g5> no :-)
<[ARP]hoijui_g5> seems fine now :-)
<[RoX]Tobi> unfinished features: that's just your 2-4 weeks, [LCC]jK? (concluding that from who's doing what)
<[LCC]jK> bugs I know of: largebeamlaser don't get drawn, sticky keys, some mouseclicks don't get processed
<zerver> i close it
<[ARP]hoijui_g5> good
<[LCC]jK> yeah, Tobi
<[RoX]Tobi> I have some too, in particular one nasty one that crashes everyone in game..
<[RoX]Tobi> since I still now release procedure and stuff, I shall just make RC in 3-5 weeks then
<[ARP]hoijui_g5> pureint may get in before the RC, if i get a suden motivation boost
<[RoX]Tobi> :)
<[RoX]Tobi> ok
<[ARP]hoijui_g5> ok
<zerver> rendering bugs can be expected, since rendering is rewritten
<zerver> i have one bug, diagonal lines drawn across the whole screen
<[LCC]jK> btw I don't know what's wrong with largebeamlaser, I would be beholden if someone else looks for it
<[RoX]Tobi> I need to go already unfortunately, maybe we can discuss new buildbot / new infolog site and bb installer problem next week, [ARP]hoijui_g5?
<[RoX]Tobi> I would suggest we all file the bugs we found/find in mantis
<[RoX]Tobi> so bugs just sit there
<[RoX]Tobi> or in that to do list in etherpad
<zerver> yup
<[RoX]Tobi> if it are tiny bugs
<[ARP]hoijui_g5> ok Tobi
<[ARP]hoijui_g5> will you setup etherpad, Tobi?
<[RoX]Tobi> yeah sure
<[ARP]hoijui_g5> ok :-)
<[RoX]Tobi> I'll poke at installing it on spring rts
<[RoX]Tobi> and if that doesn't succeed soon enough I'll pick a free host
<[ARP]hoijui_g5> thanks
<[ARP]hoijui_g5> perfect

Next meeting
<[RoX]Tobi> * Next meeting
<[RoX]Tobi> next week same time?
<[RoX]Tobi> [ARP]hoijui_g5: next week same time fine with you?
<[ARP]hoijui_g5> yes
<zerver> yes
<[RoX]Tobi> [CoW]Kloot: next week same time fine with you?
<[CoW]Kloot> same here
<[RoX]Tobi> [LCC]jK: next week same time fine with you?
<[LCC]jK> yes
<[RoX]Tobi> ok lets stick it at that time then for now
<[RoX]Tobi> then IMO you can discuss anything else you want
<[RoX]Tobi> and I'll go and see you next week :)
<[RoX]Tobi> and I'll make minutes this evening probs
<[LCC]jK> I have to go voting :D
<zerver> !votekick
<[RoX]Tobi> if you have points for agenda for next week, drop me a PM
<[RoX]Tobi> laters
<[CoW]Kloot> ciao
<[RoX]Tobi> and sorry I need to go so fast :s
<[LCC]jK> bye

End

After-meeting continuation of some technical discussions
<[CoW]Kloot> btw one thing jk
<[ARP]hoijui_g5> bye
<[CoW]Kloot> about your shader changes, did you get the idea to rewrite the classes just recently?
<[LCC]jK> no I have it for 2-3weeks
<[ARP]hoijui_g5> Kloot, about NullSound
<[CoW]Kloot> ok, then this is a good example of being aware of the importance of each other's plans :)
<[ARP]hoijui_g5> it only really makes sense for if you want sound off all the time, right?
<[LCC]jK> :)
<[CoW]Kloot> since you are undoing some of my work and taking extra for yourself
<[LCC]jK> yep
<zerver> nullsound makes sense if you have sound problems
<[CoW]Kloot> [ARP]hoijui_g5, true, most people don't switch sound off for just 5 mins ingame
<[ARP]hoijui_g5> i mean..
<[ARP]hoijui_g5> it would not be used for muting then
<[ARP]hoijui_g5> the problem there would be.. for long running sounds
<zerver> not for muting
<[ARP]hoijui_g5> ok
<[ARP]hoijui_g5> good then
<zerver> it shall work exacltly like the water, where you can reload bumpwater, reflective water etc
<[ARP]hoijui_g5> hmm.. i dont know really how it works there ;-)
<[ARP]hoijui_g5> you have to restart for changes to take effect?
<zerver> nothing special, a common base class with virtual functions
<zerver> no restart
<[ARP]hoijui_g5> and its saved in settings?
<[ARP]hoijui_g5> ah ok
<[ARP]hoijui_g5> ok.. so you we will have both:
<[ARP]hoijui_g5> mute/un-mute
<[ARP]hoijui_g5> + sound-off/-on
<[ARP]hoijui_g5> the second being the switch between CSound and CNullSound
<zerver> sound = BaseSound->Get("nullsound")
<[ARP]hoijui_g5> i mean.. the way it works for the user
<zerver> exactly
<[ARP]hoijui_g5> ok
0 x

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

Re: Dev meeting minutes 2010-05-09

Post by aegis » 10 May 2010, 02:44

you don't need to include springheadless in the default make target to merge to git master.
people can prompt a manual build or build it themselves if they want it.
0 x

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

Re: Dev meeting minutes 2010-05-09

Post by hoijui » 10 May 2010, 11:14

that is exactly what we want to do. the problem with this is, if nobody builds MT and headless regularly, they will decay fast. this can be solved by a buildbot which does scheduled builds of all build targets (each commit, or once a day).
0 x

User avatar
Das Bruce
Posts: 3544
Joined: 23 Nov 2005, 06:16

Re: Dev meeting minutes 2010-05-09

Post by Das Bruce » 10 May 2010, 13:51

What is all this talk about shaders whatnot? Is there any chance of shadows being fixed as part of this?
0 x

User avatar
Petah
Posts: 426
Joined: 13 Jan 2008, 19:40

Re: Dev meeting minutes 2010-05-09

Post by Petah » 10 May 2010, 13:57

I would love to see headless and MT versions readily available for download.
0 x

User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

Re: Dev meeting minutes 2010-05-09

Post by jK » 10 May 2010, 14:29

Das Bruce wrote:What is all this talk about shaders whatnot? Is there any chance of shadows being fixed as part of this?
Depends on what you mean.
It will solve some issues, so you will be able to enable shadows and los view at the same time.
0 x

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

Re: Dev meeting minutes 2010-05-09

Post by FLOZi » 10 May 2010, 14:57

perhaps he means this:

Image

You said in the thread I posted it
That's a problem with the current way shadows are handled. It's easy to fix with my custom unit shader gadget.
Disclaimer: I've no idea if this is already fixed in git
0 x

User avatar
Das Bruce
Posts: 3544
Joined: 23 Nov 2005, 06:16

Re: Dev meeting minutes 2010-05-09

Post by Das Bruce » 11 May 2010, 03:10

jK wrote:
Das Bruce wrote:What is all this talk about shaders whatnot? Is there any chance of shadows being fixed as part of this?
Depends on what you mean.
It will solve some issues, so you will be able to enable shadows and los view at the same time.
I mean they're broken, both with Flozi's example and with Roam rendering.
0 x

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

Re: Dev meeting minutes 2010-05-09

Post by Kloot » 11 May 2010, 12:23

Why don't you explain in your own words exactly how they are "broken", instead of basing your opinion on third-hand information about very specific cases that only show a tradeoff (better use of available shadowmap resolution vs. degenerate projections) of the current implementation?
FLOZi wrote:Disclaimer: I've no idea if this is already fixed in git
It isn't.
0 x

User avatar
zwzsg
Kernel Panic Co-Developer
Posts: 7017
Joined: 16 Nov 2004, 13:08

Re: Dev meeting minutes 2010-05-09

Post by zwzsg » 11 May 2010, 12:43

I could live with broken shadows, I'm too busy harbouring fears about whether next Spring will run at all on my ATI.

Hmm, there is no delete button in there. I hope for the best, and thanks for making the meeting log public, it's always interesting to know beforehand where Spring is headed.
0 x

User avatar
Das Bruce
Posts: 3544
Joined: 23 Nov 2005, 06:16

Re: Dev meeting minutes 2010-05-09

Post by Das Bruce » 11 May 2010, 13:12

Kloot wrote:Why don't you explain in your own words exactly how they are "broken", instead of basing your opinion on third-hand information about very specific cases that only show a tradeoff (better use of available shadowmap resolution vs. degenerate projections) of the current implementation?
Because I lack the technical understanding of how they work to do so. I can point you to where it is visible that they are wrong, such as when viewing the shadow cast from smoke it is in a different position depending on where you are viewing from, they can be seen to visibly shift as you pan the camera.
0 x

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

Re: Dev meeting minutes 2010-05-09

Post by Forboding Angel » 12 May 2010, 08:17

zwzsg wrote:I could live with broken shadows, I'm too busy harbouring fears about whether next Spring will run at all on my ATI.

Hmm, there is no delete button in there. I hope for the best, and thanks for making the meeting log public, it's always interesting to know beforehand where Spring is headed.
Seconded. Even if (or though, depending on the situation...) I have nothing useful to add (such as this post), it's nice ot be able to read up and know what's going on behind the scenes.

Speaking of useful comments, if it helps at all, I would LOVE to see mt be the default. Imo it's a very necessary and overdue step in Spring's development process. I am aware that the issues of mt are not easy to solve and it won't happen overnight, but I'm really happy that it's being worked on so vigorously :-)
0 x

Tobi
Spring Developer
Posts: 4598
Joined: 01 Jun 2005, 11:36

Re: Dev meeting minutes 2010-05-09

Post by Tobi » 12 May 2010, 10:30

http://etherpad.springrts.com/

May be useful for collaborating on some code or whatever, besides the purpose we'll try to use it for.
0 x

Post Reply

Return to “Meeting Minutes”