The following warnings occurred: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Warning [2] Undefined array key "lockoutexpiry" - Line: 94 - File: global.php PHP 8.1.27 (Linux)
|
IRC meeting Dec 2010 topics & summary [CLOSED] - Printable Version +- Forums (https://www.vdrift.net/Forum) +-- Forum: Project (https://www.vdrift.net/Forum/forumdisplay.php?fid=4) +--- Forum: Development (https://www.vdrift.net/Forum/forumdisplay.php?fid=9) +--- Thread: IRC meeting Dec 2010 topics & summary [CLOSED] (/showthread.php?tid=1388) |
IRC meeting Dec 2010 topics & summary [CLOSED] - thelusiv - 12-04-2010 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.
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. - zimluura - 12-09-2010 meant to post some possible topics here * career mode * making tracks look better - thelusiv - 12-09-2010 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. Meeting summary: Introductions - thelusiv - 12-12-2010 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 ;) Meeting summary: Project Goals/Mission - thelusiv - 12-12-2010 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 Meeting summary: Contribution - thelusiv - 12-12-2010 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. Meeting summary: Tools - thelusiv - 12-12-2010 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 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 Meeting summary: Releases - thelusiv - 12-12-2010 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 - thelusiv - 12-12-2010 Closing thread. If you would like to add to the discussion, see the linked threads for discussion topics in the last few posts. |