Bugs, Testing and Servers
We have recently added a third publicly accessible Eve server called ‘Entropy’, which is listed in the newer versions of the Eve client as ‘Test Server’ [Chaos is still available as ‘Development Server’]. Entropy is a small multi-node setup that’s just a bit closer to the state of Tranquility (TQ) than Chaos is, and will run the current TQ version for testing purposes until the creation of a new release candidate build. This whole testing setup gives us a much better platform to anticipate problems with a patch to TQ before it actually happens. There will not, in all probability, be a setup like the Fight Club Corp (as there is on the Development Server) on the Test Server.
We’re also completely reworking the bug reporting process here at CCP, which is my current job here. In order to do this I’m building a new system from scratch to suit our rather individual needs, in preference to using an existing system like Bugzilla or FogBUGZ. Of course, I’d better back up the reasoning behind this before I’m swiftly ripped to shreds by some of the more strongly opinioned members of the community.
One criterion for the system is that it has to support a threaded development model where one stage of release can be developed and tested at the same time as the current release stage is being worked on. This development model also required that we better track the versions where problems appear and where they are fixed, since having bugs and problems that are closed in one build while still affecting other builds is entirely possible.
[Hypothetical example: a certain problem is listed and tracked by the QA department here at CCP for the Shiva release, but this problem won’t affect the current Castor branch on TQ, despite it being an ‘Open’ problem. The reverse of this would be a problem that is open only in an earlier interval]
Most systems use a more conventional concept where the only thing that exists is individual bug reports – we’ve often found that there are single problems get many reports, where it is often beneficial to look at it as a single entity with many reports containing further information attached to it (a system of duplicates is similar, but not quite equivalent).
Another focus of the design of our new system is that we’re trying to reduce the feeling that some people have with the current system that your bug reports disappear into a black hole, never to be seen again. The new system will be able to support much better 2 way communication than the old system, while respecting the privacy of players posting bug reports. I’m not willing to make explicit promises this early into the process, but I have listened to the complaints about the system that is currently in place, and I am working to try to ensure that the new one is a big improvement.
