|
12-03-2010, 10:01 AM,
|
|
|
thelusiv
Administrator
|
Posts: 2,346
Threads: 223
Joined: Jun 2005
|
|
nomoo Wrote:What about using something like 'trac'? it will merge wiki, svn, bugtracker, etc. I'm not quite sure but seems to be handy. Trac is OK (there are a lot of other solutions too...) but we already have most of the tools, just not the unified login. It is more important that we decide to use them and how. vdrift.net also needs some site updates (maybe a total overhaul), but i think that's probably better left to a separate thread...
NaN Wrote:I don't see the point of keeping data backwards compatible except keeping someone busy writing/updating scripts. We are tagging data revisions per release already. If the user wants the latest bells and whistles he should use the latest binary, tagged data.
Maybe I got you wrong. I am usually using scripts to update the data when changes arise. I don't see the value of keeping them.
I think we are thinking about different approaches to the problem of data migration. But the details aren't important, it sounds like what you are doing now is fine. It's more important to work on stabilizing the format (which you are already doing), and focus on improving tools for creating data (a track editor, etc.) than worry too much about versioning (yet).
|
|
|
|
12-05-2010, 03:02 PM,
|
|
|
joevenzon
Administrator
|
Posts: 2,679
Threads: 52
Joined: Jun 2005
|
|
fudje Wrote:But on a serious note, before thinking about the next release, it's possible more effort should be put into what on
http://code.google.com/p/vdrift/issues/list is actually at what priority, and how many issues can be closed already. Then fix everything that's still critical, make a release, and assign tasks for future releases.
I think this is the way to go. I'm a little scared of having too much project management because it's a free-time project for everyone and holding people to deadlines is not fun, but at least listing and prioritizing tasks so when people have free time they can go and grab a task would be great.
To make this work, some person or persons would need to keep the issue list updated (if you see a bug report on the forums that you aren't going to immediately fix, put it in the issue tracker or tell them to put it in the issue tracker), keep the list prioritized, and figure out when a release should happen.
thelusiv Wrote:NaN Wrote:Not sure if my contributions to VDrift have been for good at all. I would say you have done much good, and hope you will continue.
Seconded!
|
|
|
|
12-05-2010, 05:35 PM,
|
|
|
thelusiv
Administrator
|
Posts: 2,346
Threads: 223
Joined: Jun 2005
|
|
joevenzon Wrote:I think this is the way to go. I'm a little scared of having too much project management because it's a free-time project for everyone and holding people to deadlines is not fun, but at least listing and prioritizing tasks so when people have free time they can go and grab a task would be great. I agree that the project doesn't need a ton of management. I guess it might look like I do from this thread and the IRC meeting stuff... I just think there should be some simple ideas put in place to help people work together. That is not to say that people aren't already working together, just that maybe it could be made simpler.
joevenzon Wrote:To make this work, some person or persons would need to keep the issue list updated (if you see a bug report on the forums that you aren't going to immediately fix, put it in the issue tracker or tell them to put it in the issue tracker), keep the list prioritized, and figure out when a release should happen. I am willing to help with managing the issues. I bet nobody else wants to anyway.  But I will need help from the people contributing. I would try to make it as little work possible for everyone. It's not important to put a lot of work into talking about problems, better to actually work on them.
|
|
|
|
12-12-2010, 05:21 AM,
|
|
|
thelusiv
Administrator
|
Posts: 2,346
Threads: 223
Joined: Jun 2005
|
|
Releases were discussed in the recent IRC meeting. Here is the summary: http://vdrift.net/Forum/viewtopic.php?p=11685#11685
We reached the conclusion that the next release should be made when the replay system is fixed. We also agreed that the project should use a main development branch (on both the code and data repositories) for development of new features, as well as the trunk which will be for the stable version.
We did not reach a conclusion on how often to release, however some suggestions were made: - release every 4-6 months
- release (automatically?) when someone merges something from development branch to trunk
- do not mix feature-based release strategy with fixed release intervals
- use a merge window to get new features into the stable version on time for release (otherwise make them wait until the following release).
I've mentioned that I am willing to help with preparing for releases, migrating code from development to stable, and updating the issue tracker. How does everyone feel about the following:
We should release after replays are fixed as discussed in the meeting. During the release process, we should create the development branches in the source code and data repositories, and start actively using an issue tracker. Following that, we should plan for a two-month merge window, followed by a two-month integration/testing/bugfixing period. After those four months, and when the trunk is stable again, we can push out another release, and repeat this process.
I'm interested to learn how other projects use merge windows. I'll research this topic more as we get closer to being ready for release.
|
|
|
|
12-17-2010, 10:23 AM,
|
|
|
NaN
Posting Freak
|
Posts: 2,024
Threads: 120
Joined: Jan 2010
|
|
Can I have a list of the cars that will be included in this release(the same as the last time?) to fix their mass distribution at least.
- Should the replay functionality be disabled. Or should we add a warning in the gui. See: http://vdrift.net/Forum/viewtopic.php?t=1367
- I'd like to look into the AWD issue reported by zimluura. Fix export scripts.
- The F1 engine sounds strange(to me). Need to compare with the previous release.
- Suspension compatibility warning should only be emitted in the debug builds?
|
|
|
|
12-17-2010, 10:48 AM,
|
|
|
thelusiv
Administrator
|
Posts: 2,346
Threads: 223
Joined: Jun 2005
|
|
NaN Wrote:Can I have a list of the cars that will be included in this release(the same as the last time?) to fix their mass distribution at least. I like the idea of only distributing a minimal set of working data, which is known to be licensable under GPL. To my knowledge, we could package VDrift with the XS and TL2, as these are original cars made for VDrift, as well as the track Rouen which as far as I know is our only GPL-licensable track. We really should do this to address this problem:
http://vdrift.net/Forum/viewtopic.php?t=665
NaN Wrote:Should the replay functionality be disabled. Or should we add a warning in the gui. See: http://vdrift.net/Forum/viewtopic.php?t=1367 We could probably spend a lot of time and menu space adding warnings about broken things in the GUI. I think a "Known Issues" section of the release notes would be enough to let the user know about any possible problems. I don't think we have to fully disable the replay system, after all, it still works fine as long as you don't drive into walls.
NaN Wrote:I'd like to look into the AWD issue reported by zimluura. Fix export scripts. The export scripts aren't included in VDrift packages, so I would say leave that until after release. If we don't include any AWD cars in the package then we could wait until after release to fix that as well.
NaN Wrote:The F1 engine sounds strange(to me). Need to compare with the previous release. I noticed that too - the popping in the engine sound. This bug has been a problem before and it looks like it's back. 2010-06-30 didn't have it.
NaN Wrote:Suspension compatibility warning should only be emitted in the debug builds? I think since we don't have anything like the auto-updater Joe posted about, we should probably complain very loudly about incompatible data. Most users won't see the logs anyway, so go ahead and make it output at car load time for both debug and non-debug builds.
|
|
|
|
