Message Board
| Message Board > Boolean Soup Development > Multiple people working on the code and rolling out features |
| January 17, 2008, 21:06 | |
|
Fiona
games are terrible -9616558 posts 
|
Well now we have a bug tracker and we should all have SVN access soon enough, we should start thinking about how the development will work, since this is going to be pretty tricky. Here's my suggestion: * Everytime we go to edit code we should update our local files from the repository and use SVN's locking feature to lock files we work on. When we're done we re-upload it. We should update after every coding session unless we break another feature. (Half finished modules should still be updated.) * The bug tracker let's us assign bugs to developers, we should do this for smaller things, perhaps larger modules and features should be assigned to multiple people, or maybe we should have a time-limit system. (If you claim something and don't work on it for a month someone else can take over?) Up for discussion. * We should have a seperate install of the website for testing in-development versions of the site. There are a few reasons for this. If you're changing something you could potentially break something else, so it should be vigorously tested before put live. We shouldn't rely on testing locally due to different versions and configuration. Having everyone FTP'ing to the website and overwriting stuff or doing something that someone else dosen't like is a recipie for disaster. * So when to decide when we update the live site? We should use Mantis' roadmap feature. For each future release we mark bugs or features that need to be written. We test all of them as they're being done. When the features and bugs for a particular release are done and it's been tested then we designate someone to upload the latest version from the svn to the live site. This is just all my opinion, it's all up for debate, but this is the best way I can think that is safe, controlled and would make for the least amount of arguments and drama. (AS if.) Feel free to put anything forward. [Edited on January 17, 2008 by Fiona] ____________ laffo |
| # | |
| January 17, 2008, 21:37 | |
|
Frimkron
Frustrated Megalomaniac 703 posts 
|
I'm not so keen on locking files. I dont think its necessary if we communicate adequately about what we're doing - it would just end up with someone locking a file and nobody else being able to make changes to it again. Subversion and the like are very good at merging multiple users' changes into one file.
____________ |
| # | |
| January 17, 2008, 21:49 | |
|
Htbaa
Perl 368 posts 
|
All sounds good. I've thought about testing the stuff and doing so on a local test environment. It would be the best solution, but we really would need the file locking stuff for this. We also need to know what version of PHP we are able to use, what MySQL version (or whatever db is being used, if MySQL: What storage engines are available). Also, if someone changes something on the database we should all be updated about it. Considering that a databases' structure is very important I don't think it's smart to just add your own tables. That stuff is important and I mean it. I'm not familiar with Mantis but it's a tool that has to be used. The timeline idea sounds good. ____________ blog.htbaa.com |
| # | |
| January 20, 2008, 20:40 | |
|
Rincewind
programmer 1554 posts 
|
All sounds good to me too. When I start joining in development, I'll just follow what you guys say and what Frimkron has written in his e-mail as I'm new to using SVN. Quoting Fiona: We should have a seperate install of the website for testing in-development versions of the site. There are a few reasons for this. If you're changing something you could potentially break something else, so it should be vigorously tested before put live. We shouldn't rely on testing locally due to different versions and configuration. Having everyone FTP'ing to the website and overwriting stuff or doing something that someone else dosen't like is a recipie for disaster. Yeah so just for the record, the development version can be found at http//dev.booleansoup.com. Anyone who gets access to the repository should get access to this (by asking any of the current developers). If needed, multiple people can test their own versions at the same time (using different subfolders), as it is possible to create new databases using the dev control panel. ____________ Personal website: http://www.loijson.com |
| # | |
| January 20, 2008, 21:42 | |
|
Htbaa
Perl 368 posts
|
That's cool. * When updating your files FILL IN A LOG. It's dead anoying when there are updates and we don't know what the F happend. :-) Also, please program with the PHP setting error_reporting E_ALL (in your php.ini, don't set it in the source files). This way you'll be notified when there are variables that aren't declared, or other warnings. Just my 2 dimes ;). ____________ blog.htbaa.com |
| # | |
| January 21, 2008, 01:43 | |
|
Fiona
games are terrible -9616558 posts
|
It's usually safe to go with E_ALL & ~E_NOTICE. Biggest reason is that notices cry about undefined keys for arrays. While it's generally practice to always do that, I will tell you now that BS does not stick to any such good coding standards. Fixing the notices would be a job and a half. ____________ laffo |
| # | |
| January 21, 2008, 18:10 | |
|
Htbaa
Perl 368 posts
|
Yes I noticed. I already changed my current settings :-). But please, for new code, define variables at the right position and check if a key exists in an array. ____________ blog.htbaa.com |
| # | |
Message Board > Boolean Soup Development > Multiple people working on the code and rolling out features