Bug recording and reporting packages.
-
There are some helpful features in the tool, but if you want to do more than minor cosmetic changes you have alot of work ahead of you. The code is full of spagetti code on top of the lack of code behind, which makes it really hard to wade through. I'm sure you, the author, knows exactly where everything is and how to make the UI look at behave exactly how you want. However, most people will have difficulty. I tried to move the validation error messages on edit_bug to the top of the screen. I couldn't figure out how to do it via the css capability in a way that didn't put the error messages on top of the issue form inputs. I did post a question asking for help with no reply. My next course of action was to wade through the code, and that was just a pain so I gave up. My employer didn't want me to waste more than a couple hours on it. Also, there was the problem of how to handle incorporating changes from new versions into code customizations. Overall, moving the error messages using code just wasn't worth all the effort. Another oddity I found was when I created custom fields in 'development' and then later tried to migrate all the changes to 'production'. I used Redgate SQL Compare to migrate the structure changes and the data changes to the meta data tables. When we ran the code in production, the custom fields appeared on the form in the wrong order, but most importantly when an issue was saved the entered values went to the wrong columns. The issue had to do with how column 'meta-data' is stored, in that some code somewhere is querying the columns by the order in syscolumns and somewhere else is using the configured order in the meta-data tables. I didn't drill down to the actual problem lines of code. But the solution was to manually edit the metadata in the production database so that the order matched the syscolumns order. Sql Compare does not use syscolumns directly which is why it did not see a difference. It is bad programming practice to use syscolumns like this in the first place, and totally couter-intutive to do so when the 'column order' is supposedly defined in the 'meta-data' table. I don't remember the other issues we had off the top of my head. I did post some in the sourceforge forum. You did a good job answering many issues and I commend you for the didication. That's great if the tool works for some people, but I wouldn't recommend it. Would you rather use a tool that was designed to meet the needs of it's users, or a tool that was a learning project? I a
Mike - that's for taking the time to respond. Regarding the code full of spagetti and me knowing exactly where everything is... actually, I wish that were true. The code is hard for me too, but I would argue that even if I had done everything right, there is complexity in the requirements/functionality, so there is going to be complexity in the codebase, no matter how well organized. Bug tracking sounds simple, until you throw in configurable workflow, permissions, custom fields, and then the interaction of those things. Then it gets hard. In my blog, at http://www.ifdefined.com/blog/[^], you'll find that a lot of posts are essentially me just whining about complexity. I didn't sit down in 2002 and write the application full blown with all its features. It has evolved. But, something I want to point out is that I have not broken backwards compatibility in those 5 years. I have felt a duty to the people who trusted me enough to depend on my application not to break compatibility. But, as Microsoft can tell you, preserving backwards compatibility also contributes to a complicated codebase. You mention FogBugz. If you think my codebase is daunting, imagine FogBugz. They created their own freakin' programming language to handle their complexity issues: http://www.joelonsoftware.com/items/2006/09/01b.html[^] For another glimpse at complexity, read the "Status" section from this Jira issue. Jira is a very widely used issue tracking system: http://jira.atlassian.com/browse/JRA-1330[^] Regarding the position of the validation error messages, moving them with css, I apologize for not answering that post. I also would not be able to do it using .css. Another developer recently volunteered to help with BugTracker.NET and what I asked him to do was to make the edit_bug.aspx friendly to css positioning. We'll see how that goes. Regarding the way I used syscolumns, well, it's a bad design by me, but because of backwards compatibility issues, I may be stuck with that design. I'm glad you were able to workaround my design mistake. If nothing else, I need to update the docume
-
I'm the author of BugTracker.NET. I've made some improvements in how BugTracker.NET looks "out-of-the-box", but if you still don't like the appearance, you have a lot of control via css and some other configuration files. Here is more info about customizing the appearance of BugTracker.NET: http://ifdefined.com/doc_bug_tracker_css.html
Hi Corey, question to the author of BugTracker.NET: do you know any migration tools (in my case from FogBugz) to convert old data into BugTracker.NET DB format? Thank you in advance Gr. Sergey
-
Hi Corey, question to the author of BugTracker.NET: do you know any migration tools (in my case from FogBugz) to convert old data into BugTracker.NET DB format? Thank you in advance Gr. Sergey
Sorry, no. I'd probably go about it by just writing SQL statements like insert into [some BugTracker.NET table] select ..... from [some FogBugz table] You might find it helpful to use "SET IDENTITY_INSERT [some BugTracker.NET table] ON", which allows you to insert rows into a table without SQL Server incrementing the identity column automatically. If you do succeed with your conversion, I'd be grateful if you emailed me your SQL.
-
Sorry, no. I'd probably go about it by just writing SQL statements like insert into [some BugTracker.NET table] select ..... from [some FogBugz table] You might find it helpful to use "SET IDENTITY_INSERT [some BugTracker.NET table] ON", which allows you to insert rows into a table without SQL Server incrementing the identity column automatically. If you do succeed with your conversion, I'd be grateful if you emailed me your SQL.
Thank you for your answer. I definitely mail you SQL script if management decision will be to switch from FogBugz to BugTreacker.Net.
-
Sorry, no. I'd probably go about it by just writing SQL statements like insert into [some BugTracker.NET table] select ..... from [some FogBugz table] You might find it helpful to use "SET IDENTITY_INSERT [some BugTracker.NET table] ON", which allows you to insert rows into a table without SQL Server incrementing the identity column automatically. If you do succeed with your conversion, I'd be grateful if you emailed me your SQL.
-
-
I realize I am opening up a can of worms here, but we need an easy to use bug recording package at my current company. One to record the bugs. Allow assigning of developers, updating status, generating reports, etc... Preferably with the ability to automatically assign, and respond by e-mail. Thanks for the input and abuse! Bill
Wow... lots of great comments here. This is my take (add it to all the other opinions). Some of the pay products are great. Fogbugz, JIRA, etc. But that cost A LOT. Fogbugz is 25 bucks a month per person. We have 100 folks working at my company. There is no way they are going to buy that (I tried). Mantis, Bugzilla, etc are free... but their interfaces are kinda crappy. They are open source projects and were made for programmers by programmers. We tried a few of these and our non-tech staff were confused by them. In the end we created our own simple bug tracker . It doesn't have all the bells and whistles as some of these other systems but it caught on at my company and a few of our clients asked to use it on projects we weren't involved in, so we made a product of it. If anyone is looking for a dead simple bug tracker, check us out www.thekillingjar.com.