Bug Smashing
by Lyell Haynes · in Torque Game Engine · 08/09/2001 (5:46 pm) · 12 replies
Couple questions to start things off:
1) Obviously, this engine is not as up to date as the the current Tribes 2 version, since they've continued work on it after you guys branched your version off. I assume you all will be getting code updates from Sierra/Dynamix if any bugs on the v12 portion of the tribes 2 game are fixed that will then be passed on to us? Will this be in the form of a big download of the whole code base? a patch of only the files affected? a CVS repository?
2) If we see things in the code we don't like, such as compiler warnings about potentially unsafe data conversions, unsigned/signed mismatches, unreferenced variables, etc. should we let you know of these "bugs" we fix in the code? I'm the kind of developer that hates seeing any type of warning, no matter how trivial, and I already see some in my test build. Should we keep you updated on changes we make to the code that help improve the engine or add functionality? Will you provide a repository where code changes can be submitted for addition to future engine patches? How should we manage the code changes we make on our own with the patches you provide? Do you recommend setting up a good versioning system on our machines, like CVS or SourceSafe? I assume yes, but wanted to hear your feedback on this issue and what thoughts you've had on it already.
Thanks!
1) Obviously, this engine is not as up to date as the the current Tribes 2 version, since they've continued work on it after you guys branched your version off. I assume you all will be getting code updates from Sierra/Dynamix if any bugs on the v12 portion of the tribes 2 game are fixed that will then be passed on to us? Will this be in the form of a big download of the whole code base? a patch of only the files affected? a CVS repository?
2) If we see things in the code we don't like, such as compiler warnings about potentially unsafe data conversions, unsigned/signed mismatches, unreferenced variables, etc. should we let you know of these "bugs" we fix in the code? I'm the kind of developer that hates seeing any type of warning, no matter how trivial, and I already see some in my test build. Should we keep you updated on changes we make to the code that help improve the engine or add functionality? Will you provide a repository where code changes can be submitted for addition to future engine patches? How should we manage the code changes we make on our own with the patches you provide? Do you recommend setting up a good versioning system on our machines, like CVS or SourceSafe? I assume yes, but wanted to hear your feedback on this issue and what thoughts you've had on it already.
Thanks!
#2
From what I've seen in other open source projects, the best things to have are:
1) Code repository, separated into three sections:
a) Stable release code
b) In-Development/Beta code
c) Submissions for enhancements/bug fixes
2) Mailing list or discussion forum for everyone to post ideas/bugs/discussions.
3) Having a person devoted to managing all bug/enhancement submissions. There should also be a small group (probably just you guys, but maybe outside developers too) that will make decisions on what gets added to the release code and what doesn't. The person devoted to the submissions would handle the organization and management of the enhancements/bug fixes. The group would only handle the decisions on inclusion. The code would be in the repository for a period of time for public comment, then the committee would make a final decision.
08/09/2001 (7:29 pm)
Thanks for the quick reply, Tim.From what I've seen in other open source projects, the best things to have are:
1) Code repository, separated into three sections:
a) Stable release code
b) In-Development/Beta code
c) Submissions for enhancements/bug fixes
2) Mailing list or discussion forum for everyone to post ideas/bugs/discussions.
3) Having a person devoted to managing all bug/enhancement submissions. There should also be a small group (probably just you guys, but maybe outside developers too) that will make decisions on what gets added to the release code and what doesn't. The person devoted to the submissions would handle the organization and management of the enhancements/bug fixes. The group would only handle the decisions on inclusion. The code would be in the repository for a period of time for public comment, then the committee would make a final decision.
#3
08/09/2001 (7:32 pm)
For source control, I would recommend CVS. It has it's problems, but it's free and works :). Rick and I have the V12 and our web site source under CVS and been pretty happy with it. Both of our repositories are run on servers though, and we haven't tried running local repositories.
#4
Lyell's suggestions for repository management seem sensible.
08/11/2001 (11:37 am)
I think there are some real bugs lurking behind those disabled compiler warnings. If you work out your change submission mechanism, I can provide some fixes. And maybe a better set of Linux makefiles (with some standard targets like "clean", for instance).Lyell's suggestions for repository management seem sensible.
#5
08/11/2001 (11:50 am)
Actually there is supposed to be a v12clean in the makefiles. I don't think we fixed it yet. Well, not on Linux/OpenBSD, atleast. I'll have a look.
#6
Lyell, on your "c" item. Are you suggesting a section of the repository open for writing to the general public? or a seperate email (or other) submission process? Seems like an publicly writeable repository will get out of hand pretty quick.
08/12/2001 (7:37 pm)
Rick just recieved his copy of "CVS for large open source projects" (not the exact title). We'll be reading that shortly for tips :)Lyell, on your "c" item. Are you suggesting a section of the repository open for writing to the general public? or a seperate email (or other) submission process? Seems like an publicly writeable repository will get out of hand pretty quick.
#7
We're not working on a single open source project IMO, but on different projects, right?
Just an example: I'm very much interested in writing an Ultima 9 style game (single player) with this engine. For this I guess I'll have to change much of V12 to make it fit my needs. (Increase the terrain size, for example)
People writing, for example, a combat simulator will end up with a very different code base when they're done with their games.
I can see two conflicting goals here:
(1) I'd like keep my source in sync with the CVS tree as much as possible, so I can have the latest bug fixes and improvements, and
(2) I need to create my own, unique game executable that does exactly what I want it to do.
Is there really a conflict between these goals, and what should we do about it?
(Of course I'm NOT suggesting that we should forget about the CVS and about sharing ideas, bug fixes and code. I'm just curious HOW that should be done best!)
08/13/2001 (2:46 am)
Do you think that it'll be possible to keep one central source repository for a long time? I didn't dig very deeply into the source yet, but I guess most people, when working on their games, will sooner or later have to branch off the CVS tree and create versions of the engine that are (more or less) incompatible to others' engines. (I don't know much about CVS though, so this might not be a problem.)We're not working on a single open source project IMO, but on different projects, right?
Just an example: I'm very much interested in writing an Ultima 9 style game (single player) with this engine. For this I guess I'll have to change much of V12 to make it fit my needs. (Increase the terrain size, for example)
People writing, for example, a combat simulator will end up with a very different code base when they're done with their games.
I can see two conflicting goals here:
(1) I'd like keep my source in sync with the CVS tree as much as possible, so I can have the latest bug fixes and improvements, and
(2) I need to create my own, unique game executable that does exactly what I want it to do.
Is there really a conflict between these goals, and what should we do about it?
(Of course I'm NOT suggesting that we should forget about the CVS and about sharing ideas, bug fixes and code. I'm just curious HOW that should be done best!)
#8
My idea is for a separate submission policy, either by email or a combo ftp/email. I would think that the best way to do this would be to get about 3-4 associates together that would handle the submissions. If a user finds a bug and has a code fix for it, or has written an enhancement to the engine that they think would be useful to other people as well, then they would submit the code and an email explaining the code to a submission email address, that would then forward it on to the associates. Obviously, this system could be abused by the jerks of the world, but I think it's a pretty good method and will allow developers to contribute to the growth of the engine and allow you guys to manage those submission in a semi-sane way. I agree that a publicly writable section of the repository is a bad idea. That would just be impossible to administer, but I think you're definitely going to need a full time submission manager to handle this stuff. I can foresee that once people have really combed through the engine, more and more of them are going to write in with fixes/enhancements/comments, etc. and it's probably going to be too much for you guys to handle in addition to everything else.
08/13/2001 (7:48 am)
Lyell, on your "c" item. Are you suggesting a section of the repository open for writing to the general public? or a seperate email (or other) submission process? Seems like an publicly writeable repository will get out of hand pretty quick.My idea is for a separate submission policy, either by email or a combo ftp/email. I would think that the best way to do this would be to get about 3-4 associates together that would handle the submissions. If a user finds a bug and has a code fix for it, or has written an enhancement to the engine that they think would be useful to other people as well, then they would submit the code and an email explaining the code to a submission email address, that would then forward it on to the associates. Obviously, this system could be abused by the jerks of the world, but I think it's a pretty good method and will allow developers to contribute to the growth of the engine and allow you guys to manage those submission in a semi-sane way. I agree that a publicly writable section of the repository is a bad idea. That would just be impossible to administer, but I think you're definitely going to need a full time submission manager to handle this stuff. I can foresee that once people have really combed through the engine, more and more of them are going to write in with fixes/enhancements/comments, etc. and it's probably going to be too much for you guys to handle in addition to everything else.
#9
On the email side, I saw an submission outline on another site that required all submissions as recursive diffs off the current build. What's your take on that? I'd hate to be sorting though emails which say "cut and past this line into line 234 of game/netConnect.h...", etc.
08/13/2001 (8:07 am)
Email submissions is what Rick and I have been talking about and seems like the way to go. What would be really nice is some form direct support for submissions in CVS :) Something like every submission is a form of branch, and only someone with of full write access can merge these branchs into the main stream.On the email side, I saw an submission outline on another site that required all submissions as recursive diffs off the current build. What's your take on that? I'd hate to be sorting though emails which say "cut and past this line into line 234 of game/netConnect.h...", etc.
#10
08/13/2001 (8:51 am)
That's how the guys at Loki handle the SDL. There are only a few core developers that have access to the repository, but anyone can make submissions including bug fixes and/or modifications. However, the main developers have final say on what gets in. It work very well for them, and keeps the users happy at the same time. It might be a good idea to get in contact with them directly, see what they have to say.
#11
Right. :-)
On the email side, I saw an submission outline on another site that required all submissions as recursive diffs off the current build. What's your take on that? I'd hate to be sorting though emails which say "cut and past this line into line 234 of game/netConnect.h...", etc.
I like the idea of diffs... However, I think you'll need to take a multi-layered approach. There are going to be many instances (which you've already seen in the Bugs forum) where people submit bug reports on 1 or 2 lines in some source file ("Hey, you mispelled 'disconnect' in the documentation!" or "Function X in file Y has an unreferenced formal parameter."). For instances like this, you'll probably have to just rely on regular email submissions with the details in the email.
Now, for larger fixes/enhancements, such as "Hey, I added software 3D support, here are the changes you need to make..." - well, that will probably need some sort of diff support. I guess if a person makes more than a couple changes in a file, or makes changes to more than 2-3 files in one submission, they should submit a diff on each of those files from the previous day's daily development build and clearly mark which build it's based on.
So, I see the process as:
1) Outside developer makes their changes to the latest development build
2) Outside developer submits these changes as either a simple email with the list of items, or an email with a zipped attachment containing the changed files and a text file describing the changes.
3) Associate reviews the changes and adds them to the current development build.
4) Changes are reviews by the development community.
5) When the changes appear okay, they are added to the stable build.
You could also add another layer to this process, where the associate first adds the changes to the "proposed" build before it gets added to the "development" build. So you have 3 sections in the repository: proposed, development and stable. I think that might be appropriate for any "large" changes that would have a significant impact...
08/13/2001 (9:15 am)
What would be really nice is some form direct support for submissions in CVSRight. :-)
On the email side, I saw an submission outline on another site that required all submissions as recursive diffs off the current build. What's your take on that? I'd hate to be sorting though emails which say "cut and past this line into line 234 of game/netConnect.h...", etc.
I like the idea of diffs... However, I think you'll need to take a multi-layered approach. There are going to be many instances (which you've already seen in the Bugs forum) where people submit bug reports on 1 or 2 lines in some source file ("Hey, you mispelled 'disconnect' in the documentation!" or "Function X in file Y has an unreferenced formal parameter."). For instances like this, you'll probably have to just rely on regular email submissions with the details in the email.
Now, for larger fixes/enhancements, such as "Hey, I added software 3D support, here are the changes you need to make..." - well, that will probably need some sort of diff support. I guess if a person makes more than a couple changes in a file, or makes changes to more than 2-3 files in one submission, they should submit a diff on each of those files from the previous day's daily development build and clearly mark which build it's based on.
So, I see the process as:
1) Outside developer makes their changes to the latest development build
2) Outside developer submits these changes as either a simple email with the list of items, or an email with a zipped attachment containing the changed files and a text file describing the changes.
3) Associate reviews the changes and adds them to the current development build.
4) Changes are reviews by the development community.
5) When the changes appear okay, they are added to the stable build.
You could also add another layer to this process, where the associate first adds the changes to the "proposed" build before it gets added to the "development" build. So you have 3 sections in the repository: proposed, development and stable. I think that might be appropriate for any "large" changes that would have a significant impact...
#12
- Supports changelist (this is a big deal)
- Direct support for renaming (not a big deal, but nice)
- Multiple hierarchical repositories (could solve a lot of problems)
- Free, with some restrictions
08/13/2001 (1:03 pm)
Sounds pretty good to me :) We're also going to take a closer look at BitKeeper, anybody here have any experience with it? Some of the things I like about:- Supports changelist (this is a big deal)
- Direct support for renaming (not a big deal, but nice)
- Multiple hierarchical repositories (could solve a lot of problems)
- Free, with some restrictions
Torque Owner Tim Gift
2. I hate compiler warnings :( A lot of the time they turn out to be real bugs. Rick and I have being eyeing those warnings, but it seemed like we could either continue to delay the release, or get some external help. I must say that we haven't really worked out the whole submission process. With the number of people we expect to be helping out, this is going to be a big problem. We're definitely open to suggestions here, and hope you guys bear with us. Though we've had plenty of experience managing projects, managing a large "open source" project is something new for us.