Forums

Here is a list of possible topics to discuss at the upcoming IRC meeting. Please suggest other topics or questions that are related. Let's try to keep the topics very general, and this thread is not for actual discussion of the topics, just coming up with a list. Discussion is what the meeting is for; if you'd like to discuss a topic prior to the meeting, start a new thread.

• What are the major goals of the project, and what are the personal goals of the people involved?
  
• What is the best plan to get a release out relatively soon?
  
• How can we help keep people contributing, and what might help to get more people to contribute?
  
• What are the best tools to use?
  
• What is the best way to make decisions about project direction?

To discuss scheduling for this meeting, see this thread: http://vdrift.net/Forum/viewtopic.php?t=1461

In case you are wondering, "Why meet on IRC for these things instead of just use the forums?" The answer is that I think that some of these are issues could be resolved in about 10-20 minutes of "live" discussion, while forum discussion could take weeks for any given issue. There are other benefits to less formal discussion than writing forum posts. The forum can and will certainly be used for discussion of individual topics both before and after the meeting.

We will have to discuss all topics in the time period allotted, so we'll have to constrain each topic to a fraction of that time to get done on time. Discuss the meeting length in the other thread.

meant to post some possible topics here
* career mode
* making tracks look better

I have written up a list of about 30 questions to help guide the discussion. I probably won't use them all, but will make sure that my meeting summary includes an answer to each one. zimluura, those are good discussion points you should bring up when we're talking about future major goals for the project.

Here is the summary of the meeting as promised. I will post it by topic. Sub-topic prompts are in bold, people's names are in italics. If a person's response is not listed below the prompt then they had no response for that question (I didn't accidentally leave them out). Any times are EST.

Present at the beginning of the meeting were Venzon, thelusiv, _nan_, and zimluura (fudje joined later).

I hope I have accurately represented the meeting. Please post if you feel I've made some error. Message me if you want a full log of the meeting.

I will provide links to other topics for further discussion of those particular topics. Please use this thread for any comments on the meeting itself.


OK, let's begin the meeting. Please introduce yourself.

thelusiv: i'm Chris (28) from the southeast USA. i finished a BS degree in Computer Science about 3 years ago. i work as a software developer at a university, focusing on driving simulator data analysis and related issues. i have been working on VDrift on and off since June 2005. i am recently back from a ~1 year break.
zimluura: i'm ny dedes, live in use/virginia/richmond. built the tc6, the le, and am working on the att
Venzon: i'm joe (28), i started the project but haven't had as much time to work on it recently. i live in the northwest US and work as a software engineer for a video game company
_nan_: I am Sergej Forat a software engineer from located in Nuertingen/Germany
fudje: I'm Francis, 25, undergraduate Computer Science student from south-eastern Australia. One of my less desirable skills is the ability to accidentally turn 15 mod 12 into 5 instead of three.

How did you first hear about VDrift?

thelusiv: i think it was on happypenguin or linux game tome, which i read regularly at the time.
zimluura: found it on the internet, wanted a good car racing game for pc
_nan_: looking for an os car racing game

What is your favorite thing about VDrift?

thelusiv: that is hard to say, but i guess what attracted me in the first place was that this racing simulator was fully open source *and* it had high-quality physics.
Venzon: it's a wide enough project that there are a lot of fun bits to work on
zimluura: that i can build stuff for it, and that, since it's opensource, it can evolve
_nan_: source code access ;)

In your opinion, what is the *one* most important feature which VDrift really needs?

Venzon: networked multiplayer
thelusiv: networked multiplayer
zimluura: gameplay: career mode, with car inventory and parts inventory (that way the player can collect stuff). on the tech side: shared object references in tracks
_nan_: getting track objects physics/shared assets implemented would be cool

What are your reasons for contributing to VDrift, and what are your goals?

Venzon: i get a lot of experience with different types of game programming and i get to see what works and what doesn't after a bunch of users get their hands on it
thelusiv: i am currently working on a Driver Training system which will be used for a research project related to my job. as my role in that project ends, i hope to spend some time to help VDrift become a more successful project.
zimluura: it's fun to do some 3d modeling. i think a long term goal would be for vdrift to overtake all other racing games/sims
_nan_: Being able to try things out, to learn what works and what not. Game programming is not my specializaton actually.

Should the project have a stated mission?
(examples: http://www.ubuntu.com/project | http://www.mozilla.org/about/mission.html | http://about.openoffice.org/ | http://www.gnome.org/about/ )

zimluura: i'm not really sure
Venzon: i have no opinion either way
thelusiv: i think this is a good idea, to give the project some direction. however it should not be too specific
_nan_: difficult, it is a simulation and a game at the same time

What should the major goals of the project be?

thelusiv: multiplayer (networked and not), increase popularity, improved interactivity, better data authoring tools
Venzon: multiplayer, physics, graphics, gameplay modes
zimluura: better bling for the tracks/racing environment
_nan_: multiplayer i guess

What is the best way to make future decisions about project direction?

thelusiv: hold meetings like this
Venzon: see what people want to work on, put people that want to work on the same thing in contact so they can work together on it
zimluura: for big things (direction things), yeah, meetings. smaller things like working gauges. maybe forum posts will do
_nan_: don't know, it heavily depens on contributors interests/motivation right now. see multilanguage support

This topic deserved more discussion so here is a new thread related to project purpose: http://vdrift.net/Forum/viewtopic.php?t=1470

What, if any, issues currently make it harder for you to contribute?

zimluura: just recently the freeform car models list has made it drastically easier for me to contribute. so i'm very happy atm. something that could be good is to code a way to mirror suspension .car setups from l -> r would make for a briefer .car file, and less chance of bugs creeping in the data entry side
thelusiv: lately, data formats have been changing a lot and my branch gets out of sync with what's in the data repository.
Venzon: besides lack of time, lack of (up-to-date) prioritized bug/task list

What, if any, changes would make it easier for you to contribute?

thelusiv: do more branching. whenever new major features or refactoring is done, make a branch, and also branch the data repository at the same time.
_nan_: i think i should stop working on mulltiple things at once, but the temptation is great and the resistance is low
Venzon: an issue tracker would be nice, although maintaining it can be a pain, which is why i stopped maintaining it... maybe what would help is better integration between our SVN repos and the issue tracker so we can automatically make issues or update issues from checkin notes

What is the best way to encourage contributors to continue?

thelusiv: remove any barriers which are hindering their work or making it less enjoyable for them.
zimluura: you're going to hate me...but for _nan_ to keep implementing new cool features that break the old data.
_nan_: adress/prioritize their issues


There was some side discussion here:

_nan_: i am the source of the issues, i gues i abstain
Venzon: well, by making it easier for zim you made it harder for thelusiv :-)
thelusiv: _nan_: i don't blame you. we don't have a way to deal with data format changes easily right now. this has been a problem before too
Venzon: thelusiv, did you branch the data repo when you started your branched code?
thelusiv: Venzon: as far as i know, the data repo has never been branched.

Should VDrift switch from Subversion to some form of DVCS? If so, which DVCS (Bazaar, Git, Mercurial, ...)? Why?

zimluura: i've heard git is good. but i've only ever used svn, and only for vdrift
thelusiv: i think we should switch to a DVCS.
Venzon: DVCS are neat, and it is nice to be able to checkpoint my changes without checking them in to the central repo and breaking it for everyone.... [...] if there's some benefit to switching, we should switch. DVCSs are cool
_nan_: i have no strong opinion on the vcs, will take what i get
fudje: Git in particular makes it very easy to pick and choose code from another branch without too much overhead. Also when a contributor has some stuff that they feel is ready, you can easily merge to a new branch and test it, and if it works out well that process can be applied to the main branch as well.


side discussion (here I am just copying the conversation verbatim because we got off topic, but it all seems important):

Quote:(12:06:29 AM) thelusiv: i think this [DVCS] would address the data sync problem i have
(12:06:44 AM) Venzon: how?
(12:07:37 AM) thelusiv: well it would make it easier for someone to keep their changes local to their machine, and push them all at once
(12:08:00 AM) Venzon: how would that help you?
(12:08:06 AM) Venzon: for this specific problem?
(12:08:23 AM) thelusiv: well i think data changes would be more isolated and happen more slowly
(12:08:33 AM) thelusiv: i guess, branching data repo would still be a good idea...hm
(12:08:50 AM) Venzon: slowly is bad :-)
(12:09:14 AM) thelusiv: yes, maybe slowly is the wrong word
(12:09:46 AM) thelusiv: more gradually?
(12:09:54 AM) thelusiv: idk
(12:09:58 AM) Venzon: DVCS are neat, and it is nice to be able to checkpoint my changes without checking them in to the central repo and breaking it for everyone....
(12:10:10 AM) thelusiv: that was kinda what i was trying to say...
(12:11:02 AM) _nan_: i guess it's my incremental updating of the data, love to get feedback asap
(12:11:02 AM) Venzon: yeah, but that's not you data problem
(12:11:53 AM) _nan_: i could try to defer the commits
(12:11:56 AM) thelusiv: yeah, really my data problem isn't that major anyway. i guess i COULD use svn better to use old revs of the data repo
(12:12:21 AM) Venzon: would it make it easier to apply patches from people without central repo access if we use DVCS?
(12:12:22 AM) thelusiv: maybe all i need is some way to tell which code goes with which data
(12:12:51 AM) thelusiv: _nan_: yeah, i don't want to get in the way of you getting feedback on changes.
(12:13:17 AM) thelusiv: Venzon: i think so
(12:13:37 AM) thelusiv: then we just have to authorize them to push
(12:13:42 AM) thelusiv: afaik
(12:13:48 AM) zimluura: how much specialized functionality is in your branch? would there be any call for the trunk assimilating the branch entirely?
(12:13:56 AM) Venzon: thelusiv, the way i look at it, you're working in the branch, you should have branched your data too....
(12:14:14 AM) thelusiv: Venzon: good point
(12:14:28 AM) Venzon: but we could always put data+code in the same data repo
(12:14:58 AM) thelusiv: zimluura: it's mostly orthogonal to other parts of VDrift. but it may end up not being so, and i just branched to avoid messing up new feature development
(12:15:30 AM) _nan_: should the development happen in branches exclusively?
(12:16:22 AM) thelusiv: _nan_: good question, i would say yes
(12:16:45 AM) thelusiv: and with DVCS, every pull (checkout) is a branch
(12:16:48 AM) Venzon: nan: would doing it that way cause much extra work for you?
(12:17:07 AM) _nan_: i'd miss the testers
(12:18:10 AM) Venzon: i don't think it's worth it, then
(12:18:34 AM) thelusiv: what about having two main branches
(12:18:54 AM) thelusiv: one for new features development
(12:19:01 AM) zimluura: i think that could help get releases out quicker
(12:19:26 AM) zimluura: err more frequently
(12:19:33 AM) thelusiv: and trunk would get new features merged in when they get finished
(12:19:48 AM) _nan_: a dev branch and a stable?
(12:19:52 AM) thelusiv: that way testers wouldn't need to check out every new branch, but just follow the development branch
(12:19:55 AM) thelusiv: _nan_: exactly
(12:20:22 AM) _nan_: sounds good
(12:20:27 AM) Venzon: works for me

We did not come to any final conclusion about DVCS or which one to use, although it seems everyone was either indifferent or for using a DVCS. This topic is a good one for further discussion. However the branching topic came up, and we all agreed that having a main development branch as well as the stable (trunk) version of VDrift was a good idea.

Further discussion of this topic belongs in this thread: http://vdrift.net/Forum/viewtopic.php?t=1469

At this point, fudje joined the conversation.

Should major releases be made at a fixed interval (i.e. every x months)? If so, how long?

zimluura: yes, i'd say 4 or 6
Venzon: doing more frequent releases would be great. [...] if we do a stable branch and a development branch, then we could potentially release whenever someone has time to go through the process. [...] i'm kind of gravitating toward the idea of pushing a release (hopefully automatically) anytime someone merges something from the development branch to the stable branch
fudje: Well just based off that I'd say that the project doesn't have enough "active" contributors for a fixed release term unless you want to be very flexible about the target dates. [...] There'd need to be at least one person dedicated to that stable branch while it's diverging from the development branch.
thelusiv: i think we should set a target date, and use that to pick a set of goals that will take about that long. if we miss a release target, oh well, set it back a few weeks and try again. [...] we'd need to only commit to features which people plan to work on, and keep the goal list short so we will have plenty of time
_nan_: i'd like to avoid mixing fixed dates with goals. either feature or fixed interval releases

Should a goal set for releases be chosen by the developers in advance?

thelusiv: _nan_ makes a good point, i agree with that
fudje: I think the best model is probably to have a set-ish release date and a merge window. It sounds very formal but it makes working on new features a little easier. If they're not ready by the time you need to be squashing bugs only, you can set them aside for the next release. [...] The merge window idea comes from much larger projects like the Linux kernel, which use DVCS
zimluura: good point
_nan_: who is going to review what is ready? [...] i am ok as long as i don't have to do the work
Venzon: i think you can make that decision nan, with the help of testers like thelusiv

When should the next VDrift release be done?

Venzon: what changes are in trunk right now that are different from the 6-30-10 release? and also are there any huge bugs in there right now that have to be fixed before a release?
fudje: It's most physics fixes and the multilanguage stuff isn't it? [...] Also wishbone suspension has a conceptual design bug (Oops). I don't have time to fix it until January.
_nan_: replays are broken. i'd love to work on the suspenion, merge my branch, but that needs time [...] there are some sync issues(bullet), don't think it is an easy one
Venzon: sounds like after we fix replays we can release whenever everyone has time to do the process
thelusiv: that sounds good to me

Everything about Releases needs further discussion here in the forums. There is already a thread for it: http://vdrift.net/Forum/viewtopic.php?t=1455

Closing thread. If you would like to add to the discussion, see the linked threads for discussion topics in the last few posts.