Pages: 1 [2] 3 :: one page |
|
Author |
Thread Statistics | Show CCP posts - 5 post(s) |
Jotan Veer
HUN Corp. HUN Reloaded
|
Posted - 2007.07.06 22:27:00 -
[31]
Originally by: Cyan Nuevo
Well, this is the pivotal point. I have a feeling players that are too lazy to submit reports via the current system would just submit lazy (aka bad) reports via an easier one. ("omfg my ship just blew up. plz fix thx.")
I'm more than happy to test all angles of the bug in game, check out all variations and write a detailed bug report (yes I do take the effort) however let's not have to jump hoops in order to submit it.
See, there is a difference between spending time on writing and bug report and wasting time on submitting it. The first one is fun (at least I like it) the second one blows.
HUN Corp. recruitment status: frozen
|
Gner Dechast
Gallente Flashman Services
|
Posted - 2007.07.07 07:54:00 -
[32]
Does anyone remember the numerous times when the in-game petition system was borked? I do...
I would put a strong vote in for NOT having additional code in the client for bug reporting regardless if there is the web site version always available as an alternative. (hell, I would want to strip the client down as it is, and none of the reasons are about local performance/CPU power)
Reasonable bug reporting and tracking as a web interface can't seriously be THAT much work to use. Once long ago humans had to move their feet and perhaps whole bodies, sometimes even carry things - now it's just couple of minutes of wiggly fingers and some wrist movements for your mouse
|
Weeble XiaoXiao
|
Posted - 2007.07.07 19:53:00 -
[33]
make a link to the known issues page in bug reporting.
I knew there was a site like that but I did not remember where I had seen it. so I just reported a bug that was a known issue. later found the page under patch notes. pls have this in bug reporting to as it would be nice :) cant always remember where to look. and some of us is getting older...
|
|
CCP Lingorm
|
Posted - 2007.07.09 12:41:00 -
[34]
Some good stuff here.
As you can see some of it we are already looking at implementing (see Tanis' latest blog) and I will certainly look into the other suggestions.
As for the design by Committee, this is not a Committee, I prefer to think of it as an Ordered-Democracy. You can vote on any thing you like as long as you do as you are ordered. Seriously we do take in all the feedback and look at what we can seriously implement within constraints of resources, time and integration with our existing system (or replacement).
But that does not mean that we are not making notes of your suggestions and will implement them when possible.
Keep up the good suggestions, I will be checking in every couple of days to see if there is anything new.
CCP Lingorm CCP Quality Assurance QA Engineering Team Leader
|
|
Kimo Sabi
Minmatar United Systems Navy
|
Posted - 2007.07.09 14:27:00 -
[35]
As I said in the response to the QA dev blog thread - I'd like to see some way of identifying an age of a bug - not like "this bug create 02 Jan 2007" but some sort of tree or tiering in the known issues page which lists the bugs in the order of the build numbers they were first identified in
This should be relatively easy to tie in to a bug tracking database, for example - the default page loads up a list of current bugs by build number, eg.
Build 32517 - xxxx - xxxx - xxxx - xxxx - xxxx
Build 33752 - xxxx - xxxx - xxxx
Build 34381 - xxxx - xxxx
As this would be tied into a db, maybe have a couple of links that reloads the page and display all bugs - those that have been closed out have a strikethrough or italics, and a note with the build number that addresses the bug - A handy way of saying "We had XX bugs reported this year, and successfully dealt with YY of them"
And being a DB generated page, it sholdn't be too difficult to tie it into an authority level - so that it prevents joe public (me, for example) for seeing the nitty gritty bug reporting that's part of the development process, but would give depth where it's needed (a simple public/not public flag wouldn't be enough I feel, so a simple extension of this - are they devs? are they bughunters? are they joe public? - would give the right level of privacy/publicity)
I also like the voting idea - opening up the bug solving process to your end users somewhat. ========================================
Kimo Sabi's Mining Spreadsheet |
Carsidava
Ars ex Discordia GoonSwarm
|
Posted - 2007.07.11 21:28:00 -
[36]
I'd like to see better two-way communication between bug filers and bug hunters. It's all too often I get a bug response back that says "unable to reproduce, file a new bug with a logfile". Why can't I attach additional information to that bug if the bughunter requests it instead of having to file a whole new bug?
I'd also like to see the ability to reference specific petitions and/or previous bug reports without having to type in "this is in reference to petition XYZ". A comma-separated list of petition and bug IDs would be fine.
The two-way communication is the biggest one, though. I'm getting more and more frustrated having to file a fourth bug report about the same bloody problem because a bughunter didn't actually go to a previous bug report (whose ID I listed in the third bug report) and look up the logserver dump, and thus closed the third bug report with "not enough information". I shouldn't have to type the same thing four times and attach the same file three times while getting angrier and angrier each time around the loop, while having less and less confidence that my bug report is actually going to be listened to and acted on. |
Kimo Sabi
Minmatar United Systems Navy
|
Posted - 2007.07.12 09:11:00 -
[37]
What about a "My Bugs" page as part of eve insider - when you're logged in you can open this page up and see what bugs you have open, their status etc (possibly put a create bug report link to make it easy to navigate to). Then if you need to supply more information you can add to it.
Possibly expand this so that the known issues page allows you to attach logfiles to (some) bugs (like the dsync issue) so that lots of bug reports don't need creating - or making it so that public bugs where you need feedback/logfiles can be added to your "My Bugs" page (maybe the users only see these if they have created a bug report in the past - so you won't get swamped, and you subtly obtain a userbase of people who can assist the bughunters?) ========================================
Kimo Sabi's Mining Spreadsheet |
Cheopis
Big Rock Disposal
|
Posted - 2007.07.12 12:02:00 -
[38]
Any changes to the bug reporting system that do not include putting the bug reporting system in-game are doomed to result in mediocre participation at best.
People don't like to leave the game to enter a bug report.
In lowsec, when you are seconds from death at any given time, it is stupid for players to leave the game. If you go to a safespot and sit there for several minutes, people will map your safe spot. If you go to a station, you might get station camped. If you are a miner, you lose productivity, of you are a mission runner, you lose bonus time.
Stop making us choose between reporting bugs and playing the game. That will be the single biggest thing CCP can do to improve bug feedback.
The sad (and only even barely legitimate) argument that I have heard against ingame bug reporting is that people will misuse it. The answer to this is... So what? If they misuse it, delete the report.
... Falsebug=Falsebug + 1 If Falsebug > 3 then Playerxxxxxxxbugrep=0 ... I'd love to be able to bug report all the bugs I find, but unfortunately only the crippling bugs are worth my time out of game to do so, and I'm a highsec character. Lowsec characters are even less likely to report.
Please, help us help the game!
Thanks!
|
|
CCP Lingorm
|
Posted - 2007.07.12 16:42:00 -
[39]
Here we go.
MyBugs. First implementation is now in internal testing. Tanis is writing a new blog telling you how to use it so Expect it Soon(tm).
Now about in-game bug submission. We are looking at alternative methods of bug reporting. But nothing has been decided yet.
CCP Lingorm CCP Quality Assurance QA Engineering Team Leader
|
|
Mashie Saldana
Hooligans Of War
|
Posted - 2007.07.13 19:55:00 -
[40]
It would be great if the bug reporting get the same interface as the petitions, at least it would be possible to know who has processed a bug report and quickly supply additional information if needed.
As for general bug processing issues right now I have a great example with bug ID:40049 Title: Inconsistent heat damage on modules. It was returned and closed with the comment a logserver log is needed. The funny thing is that the issue is in the database and the module comparision tool in game works fine to study it. If the bug processing people actually read the information provided in the first place it would be a great start. After all if we, the players, take the time to write a long and detailed bug report it would be appreciated if the person reading it allocated more than 5 seconds to it.
We're sorry, something happened.
|
|
Ten GuMarr
Amarr Hedion University
|
Posted - 2007.07.15 15:40:00 -
[41]
How about updating the site with updates from a patch the same day the patch is released (or at least within a few days).
Example: Since Rev II all covert ops craft have had 3 Missile Launcher slots available however the following craft in the Item Database still show 2 launcher hardpoints and are therefore out of date
Purifier Nemesis Hound |
Akita T
Caldari Navy Volunteer Task Force
|
Posted - 2007.07.17 19:03:00 -
[42]
Whoa, "my bugs" is working... somewhat. Nice one. Question: what does "filtered" vs "attached to a defect" mean ? I have things listed as "filtered" that were fixed bugs and both rejected bugreports, and I also have "attached to defect" bugreports that (afaik) have been fixed too.
Wouldn't a status like "pending verification" / "rejected" / "attached to defect" / "issue fixed" make more sense ?
Char creation guide | Module/Rig stacknerfing explained |
Al At'ar
|
Posted - 2007.07.19 17:38:00 -
[43]
Originally by: CCP Lingorm Edited by: CCP Lingorm on 28/06/2007 14:41:52 Somethings to consider that I have been thinking hard on.
If we make all the bugs public then EVERYONE has access to use the information contained there in for what ever purpose they can. This means that we would be 'publishing' an Exploit manual. Not something we want to do. Conversely there is some merit in people comparing notes and trying to gather more information on the bug to make it easier for us to identify and then fix.
Security by Obfuscation has never really worked but there is a difference between Obfuscation and sensible exclusion of information.
We do have more detailed bug threads on the Bug Hunter Forums, but those are closed to the general public to prevent this information being put to nefarious uses.
If you have suggestions of a happy medium that can serve both results then I am ready to hear you suggestions.
Could someone please post a URL to this Mantis that is talked about please so that I can have a look.
Although I understand your position to not make matters worse a simple Google search for EVE bot miners turned up sites that charge around $20.00 a year to join and you have full access to all the known EVE bugs and exploits. CCP's attempt to hide problems in EVE seems self serving to me. You're not hiding anything from those who want the information believe me. I would like to see someplace where responsible players can inform CCP of these online posted game bugs and exploits. Everyone complains about the macro's... let's use their knowledge against them to clean up the game or I suggest CCP spend the $20 and download all the info themselves. I know what your response is already... use the bug reporting system.... this is cumbersome, limited in info sharing and a bit intimidating to use. The system should be reworked in my opinion.
|
|
CCP Lingorm
|
Posted - 2007.07.20 09:40:00 -
[44]
Here is a basic 'Bug Work Flow'
You Submit a bug and it goes into a List. This list is filtered by members of QA and the Bug Hunter's. If there is not enough Information or they can not reproduce it is is 'Discarded'. <- This is the point where My Bugs comes in allowing you to add more information and resubmit the bug. If it can be Reproduced then an Defect is created in our Internal tracking system. The associated bug reports are linked to it and all files from the Bug Reports are attached to the new defect (it is common to have multiple Bug reports attached to a single defect). Once a Bug report is 'Attached' then it is closed and we are working on the fix.
We are working on getting the State of the Defect onto the My Bug reports for those bugs that have been attached to a defect.
CCP Lingorm CCP Quality Assurance QA Engineering Team Leader
|
|
Cheopis
Serenity Syndicate
|
Posted - 2007.07.21 12:40:00 -
[45]
The problem with the current method is that it should be happening in-game.
I have submitted a couple of bugs. I never bother going back to find them again because it was bad enough that I had to leave game to report them, but it's even worse that the game isn't polling client data and auto-attaching it, nor is there an option to maintain and attach a system info file (hardware, windows version, etc) to bugs.
At this point I only submit crippling bugs, and after I submit them, I'm done with them. If the bugs interfere with my gameplay too seriously, I discontinue my account for a couple months until I read patch notes that indicate the bugs have been fixed.
I like EVE, it's a great game, but when players don't have access to a sensible bug reporting system, it's hard to get bugs reported accurately. There are many reasons for this, from apathy to lack of computer knowledge, from greed to just having a poor memory. I do technical support for a living, I _really_ don't want to do it unnecessarily for a game I play. |
Miss Mickey
|
Posted - 2007.07.23 13:25:00 -
[46]
We are currently being asked to report encounter sites that won't despawn via the bug report system. However, this seems highly ineffective. I'm finding sites which have been cleared but won't despawn. I've reported one, only to have the site finally go away before anyone got round to processing the bug report. The site was in system, empty, for nearly a week! But it took longer than that before the bug report was processed, so as far as your system seems to be concerned, there's no problem with them!
I'm not going to bother reporting any more of these (they seem to mostly be Serpentis Refuge) if I'm going to get responses that say the problem could not be duplicated. Either these are given higher priority (unlikely but hey!) or there should be a better way of reporting these.
|
Imhothar Xarodit
Minmatar Wolverine Solutions Interstellar Alcohol Conglomerate
|
Posted - 2007.07.23 15:17:00 -
[47]
Edited by: Imhothar Xarodit on 23/07/2007 15:21:56 One thing that frustrated me was the response when the bug could not be reproduced.
It would be of great help if the person who looked at the bug report could give more details in his reply than simply "we need more logs".
For example: If I give a list of reproduction steps, tell me at which point the bug hunter wasn't able to reproduce the error, or which point of my description could not be reproduced, or what exact issue in the bugreport lacks detailed information.
This way I can focus on one certian step during reproduction or in my description and check what are the exact conditions of my client when i go through step 4/10 etc.
For example: I submitted a bug report about the refining yield not being displayed correctly on the reprocessing view (it shows the yield of the highest/first specialized processing skill) and the response was: "Unfortunately, the problem described in your bugreport is such that we need a set of logfiles from your client." Now, I don't know of what exactly a logfile is required, as it is a wrong number shown on a text label on the reprocessing window. I was quite confused of what exactly the log should capture?
The bug description was very detailed, including my skills and station and explaining the numbers and where exactly they come from.
Well, enough complaining.
All in one: if the bug report cannot be reproduced by QA or BH, pelase add in your e-mail response why it was not reproducable, which step of the reproduction steps failed, what events would help most to be captured in a log file etc. This way we can focus more on the specific issue of the bug report that might be responsible for it.
P.S.: Almost forgot, the MyBugs section is really nice work :)
|
Hamfast
Gallente
|
Posted - 2007.07.23 17:39:00 -
[48]
Originally by: Imhothar Xarodit Edited by: Imhothar Xarodit on 23/07/2007 15:21:56 One thing that frustrated me was the response when the bug could not be reproduced.
It would be of great help if the person who looked at the bug report could give more details in his reply than simply "we need more logs".
For example: If I give a list of reproduction steps, tell me at which point the bug hunter wasn't able to reproduce the error, or which point of my description could not be reproduced, or what exact issue in the bugreport lacks detailed information.
This way I can focus on one certian step during reproduction or in my description and check what are the exact conditions of my client when i go through step 4/10 etc.
For example: I submitted a bug report about the refining yield not being displayed correctly on the reprocessing view (it shows the yield of the highest/first specialized processing skill) and the response was: "Unfortunately, the problem described in your bugreport is such that we need a set of logfiles from your client." Now, I don't know of what exactly a logfile is required, as it is a wrong number shown on a text label on the reprocessing window. I was quite confused of what exactly the log should capture?
The bug description was very detailed, including my skills and station and explaining the numbers and where exactly they come from.
Well, enough complaining.
All in one: if the bug report cannot be reproduced by QA or BH, pelase add in your e-mail response why it was not reproducable, which step of the reproduction steps failed, what events would help most to be captured in a log file etc. This way we can focus more on the specific issue of the bug report that might be responsible for it.
P.S.: Almost forgot, the MyBugs section is really nice work :)
I wanted to Echo Imhothar Xarodit's point...
I submitted a bug that I could reproduce (and still can) 100% of the time following 3 easy steps (perhaps my problem is the 3 easy steps are not that easy)... and I am told it can't be reproduced...
At the time I was not able to "Reopen" the bug, so I opened a second bug and tried to refer to the original ticket... I added a bunch of screen shots, step by step as I reproduced this bug twice in a row... but that second ticket has not been "Filtered" yet... this tells me that you have not even looked at it (Am I right?)...
Now that I can reopen the older ticket, perhaps I should... attaching the same files as I added to the second ticket...
Had the Email I received said "We tried to reproduce this but were unable at this point..." I would have known which of my 3 steps was not clear enough and corrected that instead of having to go through the whole mess again, resubmitting the same 3 steps and most likely making the same mistake in the reproduction steps as I did the first time.
None of us is as dumb as all of us...
|
Kirov VIII
|
Posted - 2007.07.23 17:43:00 -
[49]
Yes, give more information on the problem for reproduce the bug or ask the player to come on the test server for test the issue ...
For a lot of player if you take the time to send a bugreport. You have take the time to test and receive a : not possible to reproduce problem, it's for us (player), an easy and basic response for don't test ...
After, when it's a response like : It's a game design ... You can may be work on them. I give an example, you mine ice with retreiver at each time which you receive ice, your ice harvester is stopped (don't enough cargohold) ... You don't have this problem with covetor, hulk, makinaw, ... And it's a game design ? It's really strange for me :P (And for first response, I have the famous "basic response" : not possible to reproduce this bug .... ;o)
|
ardik
Steel Battalion
|
Posted - 2007.07.24 21:16:00 -
[50]
Personally my greatest issue with the bug reporting site is that whenever I try to access it I get this:
500 - Internal Error
The server was unable to process your request.
Support personel has been notified, no further action is needed.
½ Back
But since I've been getting it every time i've tried to access it for the last 2 months or something then I guess further action is needed :p
Anyway, encounter called drone squad does not despawn.
|
|
Commander Spectre
|
Posted - 2007.07.24 23:25:00 -
[51]
I might have found a POS bug. My POS was set to shoot anyone with a standing of less than 0.1. A neutral warped right up to the POS and nothing happened. So I took control of the guns but he warped away before I could target him. I relinquished control and went outside the bubble and my POS guns blew up my ship. I have petitioned for reimbursment but I think this needs looking into further.
|
Imhothar Xarodit
Minmatar Wolverine Solutions Interstellar Alcohol Conglomerate
|
Posted - 2007.08.04 02:27:00 -
[52]
This again is a perfect case of what I was talkig about earlier...
"The problem you have described was not reproducable. If you are still having the problem you described, could you please file another bugreport with an improved set of reproduction steps."
I really cannot be more specific on eproduction steps. It is impossible, I already said exactly what conditions have to be met, what buttons you have to click and where and I get this answer.
Can you imagine how frustrating this is? You want to help and then get this answer. And I can reproduce this every time I like...
The report ID is 39603. I really can't help myself, I don't know how to make it clearer
Put more details in your answers, please, it helps everybody!
|
Hilabana
Minmatar Sebiestor tribe
|
Posted - 2007.08.28 04:39:00 -
[53]
a server logger that broken into more then one part so that it can help in quicker problem tracking and a way the person sending in the log may know they have the errors recorded.
After the ones i sent in and they never shown any problems it makes the people sending in bugreport that are no good feel like why even bother if not one of them bloody things come to any thing.
|
Lucifer66
|
Posted - 2007.08.30 11:31:00 -
[54]
Edited by: Lucifer66 on 30/08/2007 11:31:45
Quote: Also, many of the above minor inconveniences can be avoided by playing in windowed mode when you want to report bugs.
While this is an option for some ppl...others like myself cannot play eve in windowed mode. When I try it the game lags out, then locks up. Prolly cuz I got a crap PC. But there are many other people, I'm sure, who don't have the latest and greatest PCs. So an in game bug reporting system would be far more usefull imo.
|
Slate Fistcrunch
|
Posted - 2007.09.18 11:14:00 -
[55]
I am both encouraged by the new bug system and also incredibly frustrated by the whole bug reporting system.
The new tracking and feedback are great. We can tell when our information is helpful and it is rewarding to see bugs you reported fixed in a later patch.
However trying to get the bug finding team to recognize a bug in the game is incredibly difficult and too much of the workload is being dumped on the users and not on the CCP staff / bug finding team. There is a huge gap between recognizing that there is an error in the code and having full reproduction steps. Any programmer knows there is a lot of work that has to be done between recognizing the program isn't giving the correct results and narrowing down the exact flow of actions that lead to the incorrect results. The way the bug system works currently, if the user can't give you all 10 steps from a to z, it's as if the bug doesn't exist and all of the user's work is discarded. There should be a new filter option of "problem recognized, not enough data" for situations where there obviously is a problem but no one has narrowed the problem down to the Nth degree yet. There are some bugs that require the extra resources that only CCP has to hammer down. I'll go through two recent examples to illustrate what I mean.
I made a bug report involving the overview bug where the parts of the overview become stuck behind another part. The client becomes useless after this bug. I've heard people in my corp mention when they get struck by this bug and there were numerous posts on the forums asking for help in overcoming the problem. The bug report I submitted included screenshots, the corrupt game file, and a summary of the actions I was doing when this bug struck (fleet combat, drones deployed, etc.) Now the bug finder that reads such a report is going to know there is a problem with the code by looking at the screenshots. However because I hadn't given detailed instructions on how to reproduce the problem (I wasn't able to reproduce it myself at that time), that bug report was going to be discarded and no CCP employee would've ever looked into the problem. Had I been working at CCP and someone submitted graphical evidence of a problem along with a game file that I could examine to see what went wrong, it would've been trivial to track the bug down in the code. Instead the workload was put on me as a user. I had to spend about 10 hours over the course of several days trying to reproduce the bug. I finally did find the problem but you couldn't ask me to go through that again.
My last bug report involves a new problem that cropped up since one of the last patches involving the "look at" command. My corp mates remarked on this bug immediately after the patch and it was quite obvious to all of us. Later on I ran an exploration site and I noticed explosions set off by structures exploding were bugged the same way. I bug report the problem and get the "cannot be reproduced / your effort is being discarded" response. Honestly I cannot be bothered to make zip files with edited screenshots for every bug I report. I especially won't be putting further effort into identifying bugs when I spend an hour fixing up a bug report and it's obvious the bug finder discarded my report after 5 minutes of investigation.
|
Sabe
Gallente Blood Horizon Red Horizon
|
Posted - 2007.10.02 15:06:00 -
[56]
Put it IN GAME. Same as petitions. Period. No excuses, no explanations just DO IT.
I run into bugs all the time, but I'm not going out of my way to be a beta tester for you... give us an IN GAME option to EASILY report bugs and the reports will flood in.
----- TROLL
One mans "flame" is another mans "constructive criticism". |
Arvoreen
Caldari Freedom-Technologies
|
Posted - 2007.10.31 20:03:00 -
[57]
I wanted to add my 2 cents in for a more OPEN bug reporting solution. One where all bug reports (or portions there of) are visible to all users. Mantis has already been suggested, here are some other choices...
Bugzilla or Trac or Jira.
IE, something where all bug report submissions are visible by EVERYONE. Along with a full history of actions. Where we the users can SEARCH for existing bug reports (maybe someone else has had a similar problem), and we can either add our extra information (maybe I have better reproduction steps, or logserver files, or whatever), or I can CC myself to the bug so I can see when it's going to be fixed.
Then when we submit bug reports that aren't helpful, someone else can chime in with more information. Then everyone gets to see what other people are reporting. Heck, most systems even support 'enhancement' requests with the same mechanism. Or allow for 'voting' (good/bad, up to you) on bugs, so that highly rated problems can be addressed sooner (or at least you get a clearer sense of what is frustrating the user base).
This does NOT have to replace any internal ticketing system you already have in place. Actually, it should work hand in hand with your internal system. Once it makes it there, you can easily add a identifier/status/comment/whatever to the 'public' bug to indicate it's being worked on.
This kind of transparency would make alot of people happier, and lead to better overal bug reporting. Public examples of good bugs, there for anyone to see anytime (and can be used as templates for new submissions) would go far.
As for exploits or sensistive information. All of these choices have mechanisms in place to mark either ENTIRE bugs as 'private' or specific comments as private. This would restrcit it to those users in the appropriate groups. Couple this capability with the current initial filtering by QA / Bug Hunters group, and appropriate default permissions, and you can still protect key information from leaking, while making the majority of information public.
|
Gus Preston
Gallente Dark Knights of Deneb Against ALL Authorities
|
Posted - 2007.11.16 21:25:00 -
[58]
Edited by: Gus Preston on 16/11/2007 21:24:59 On the test server my character is stuck, and has been stuck at login for 4 days now. can he be moved please, am i even in the right place for this??
|
Neon Anderson
Gallente Rising Sun Inc.
|
Posted - 2007.11.24 19:02:00 -
[59]
Edited by: Neon Anderson on 24/11/2007 19:02:43 one thing that is urgently needed on the bug reporting on the website is that you can upload multiple files to one bug report, eg if i want to upload the dxdiag and the log file also i dont mean to sound like a nag or anything but its weird, more than 50% of the time i try to make a bug report i get a website down or some similar error message :( the one that says support team has been notified, no further action needs to be taken by you... something like that :P i can understand that you can have problems with the website but that often causes me not try submitting again tomorrow as all the text i typed in the bug report are then also lost :( so ofcourse im not willing to go through all that trouble again to have the chance that it still doesnt work and i lose all the text i typed for the bug report Neon Anderson As fast as light, as strong as rock |
Chi Quan
DEFCON. Phoenix Allianz
|
Posted - 2007.11.30 11:30:00 -
[60]
is bugreporting down atm?
-- Tempus fugit -- quote spiralJunkie: it doesn't matter how you pronounce it, it still shoots you in the face |
|
|
|
|
Pages: 1 [2] 3 :: one page |
First page | Previous page | Next page | Last page |