How To Track the Bug-Trackers? 174
schneecrash writes "Submitting bug reports — and waiting for responses etc. — seems to be SOP for developers and users alike, these days. Every project has some sort of bug-tracker — bugzilla, trac, mailing list, etc. E.g., we currently track 200+ external bugs across ~40 OSS projects. Half the bugs depend on something else getting fixed, first. Every bug has its own email thread, etc. Management asks 'How we doin' overall?,' and suddenly everyone involved gets to work removing dried gum from the bottom of their shoe. What do Slashdotters use/recommend for centrally keeping track of all the bugs you track across all those different bugtrackers? In particular, managing communications and dependencies across bugs? So far, the best method I've managed to use is bunches of PostIt-notes stuck to the screen of an out-of-commission 32" TV (glossy, non-matte screen, of course!)."
Recursive Bugtracking (Score:4, Funny)
A Jira of Jiras.
This is more or less what I do (Score:5, Informative)
We track bugs internally using Bugzilla. When we raise a bug against a project we depend on, we also raise a bug in our internal Bugzilla that links to the other bug, then we can use Bugzilla's depends-on and blocks to track the external bug.
The only downside is that someone needs to go and check periodically on the state of that external bug. It would be nice if Bugzilla let you mark a bug as "depends-on" a bug in someone else's Bugzilla.
Re:This is more or less what I do (Score:5, Informative)
launchpad.net automatically watches some external bug tracker, so it must be possible.
Re:This is more or less what I do (Score:5, Informative)
launchpad.net automatically watches some external bug tracker, so it must be possible.
Launchpad can also sync comments bi-directionally with some bug trackers (Trac and Bugzillas that install a Launchpad API plugin. Bugzilla 3.4 instances will also be supported).
Disclosure: I'm a Launchpad developer.
Re:This is more or less what I do (Score:5, Funny)
Launchpad can also crash anything that flies (surviving the crash, of course).
(Mods, if you're too young to remember this, then DON'T MOD)
Re: (Score:2)
Let's get dangerous!
Re: (Score:2)
I was going for DuckTales, but Darkwing Duck works too.
Re: (Score:2, Funny)
Re: (Score:2)
It would be nice if Bugzilla let you mark a bug as "depends-on" a bug in someone else's Bugzilla.
IIRC Redhat's bugzilla fork lets you do this. The main code might at this point, I thought I saw that as an RFE.
Re: (Score:1)
Re:Recursive Bugtracking (Score:5, Funny)
and if you use LDAP instead of Crowd for user management, then in the darkness it can in fact bind them.
Basket (Score:5, Funny)
Mac user? (Score:3, Funny)
Re: (Score:3, Funny)
Re: (Score:2, Funny)
I first thought "Who cares?" but after seeing your nick, I understand why it is so important difference to you.
Re: (Score:2)
Re: (Score:2)
You mean "a low-profile circular filing cabinet"?
Stick with the post-its (Score:2, Insightful)
Re:Staples Calendars! (Score:4, Interesting)
What I think I hear you saying, translated, is "you keep manual mini-notes of 30 words or less on discrete topics."
I try to use PostIts for really ultra-short things that I know will go away in less than a couple hours. But when suddenly some topic cascades, I gather the 7-odd Postit notes and then follow the issue on a re-purposed Staples Desk Calendar. Those little squares are the same size, and lined! Then you can track some 60 episodes per page with 3-stage Progress per episode. Then when there's only about 3-4 issues left I clean up the battle scarred mess into one 8x11 sheet of paper drawn into quadrants, whose issues are typically the ones "parked". You can scan those and just look at them once a month to see if someone woke up & fixed something.
Re:Stick with the post-its (Score:5, Funny)
Seriously, I've found them to be the best method of issue tracking.
Your .NET program just crashed with a stack trace of a size that is only rivaled by Java. Please visit your postal clerk in a few days to pick up the extremely large package I sent (at considerable personal cost) containing 12,345 post-it notes.
Internal (Score:2)
Within a project all related tickets should be able to update you when one of the related tickets changes (RSS feed, email, etc).
Across multiple bugtrack systems and projects...trickier.
Re: (Score:3, Interesting)
we currently track 200+ external bugs across ~40 OSS projects. Half the bugs depend on something else getting fixed, first.
lymond01 writes
Across multiple bugtrack systems and projects...trickier.
I'm working on a lightweight system designed exactly for this problem. And when I can get enough internal interest in getting the project through the opensource process, it may see the light of day sometime in the next few months. Until then, use bugzillas dependency fields, launchpad or post it notes. Sorry.
Re:Internal (Score:5, Funny)
"Once bugzilla implements the features in the next version and/or fixes bug #233412 and #455354, and Trac patches the rss feed problem, and...well, I just don't know how I'm going to keep track of all these bugfixes so I can get my bugfix tracking program working properly!"
Re: (Score:2)
Yah...I wrote it in Word using my Windows Mobile phone.
Needs to be managed by a person... (Score:4, Insightful)
There's probably a product where developers/bug-submitters can note the priority of their perceived bug, and can do this sort of thing for you. However, it doesn't solve the problem. Developers are going to pick the most interesting bugs to fix, not the most important (they're not always the same), and bug-submitters tend to think all their problems are life and death high priority. A manager is your best bet.
Re: (Score:2)
Not always. I've submitted a number of bugs to different projects over the years, and I've never yet marked one as high priority. In fact, I made a bug report yesterday that I marked as Low, because it was recommended by SeLinux that I file a report, but it didn't have any obvious symptoms.
Fix them (Score:4, Informative)
Re: (Score:1)
Just don't write bugs in the first place and write all modules that you need for your own project.
"I didn't reinvent the wheel.. I made it better!"
Re:Fix them (Score:5, Insightful)
That sounds great, until a week in you get to a bug that you can't fix because something else is blocking it. Now you start working on that second one for about a week before you realize that it, too, is being blocked by another bug. And so, and so on. Pretty soon, you're six months in, haven't accomplished anything, and are no closer to solving those dependencies. And without mapping them out as you go, you might not know which ones to go back and fix in which order. Not to mention, not all bugs are created equal. Some you can ignore for now, some cause the entire project to stop dead in its tracks.
No, the best solution is always to stop what you're doing, back up, and make sure everything is mapped out. Better to spend two weeks doing that and get all your ducks in a row rather than running off and making things worse than they already are.
Re: (Score:2)
That sounds great, until a week in you get to a bug that you can't fix because something else is blocking it. Now you start working on that second one for about a week before you realize that it, too, is being blocked by another bug. And so, and so on.
What kind of freakin' "bug" takes a bloody week to work on?
PROTIP: Start your task by breaking big bugs into smaller bugs. Seriously, use that bug tracker to full advantage. As you figure out the issue, make new bug reports for each of the (small) pieces of the problem. Then put in the original bug that it has been subdivided into bug A, B, C, etc. Then start working on each one of those, closing them as you go.
Advantages to this:
a) In a multi-developer environment, one of the other devs might come along an
Re: (Score:2)
What kind of freakin' "bug" takes a bloody week to work on?
A hypothetical one, obviously.
Re: (Score:2)
One that refuses to happen while your watching.
jello dancers (Score:5, Interesting)
Judging by what you didn't discuss, you don't seem to distinguish fixing surface manifestations from root causes. I find that when I focus on addressing root cause, I don't run into this regression. Code is correct when it performs as specified in the design and API documents. If that means the entire application bombs out because something on the other side is broken, that's a separate consideration.
Put in the correct code (as if the other side is also correct) and then mark the bug as fixed, pending final validation when the other side is also fixed.
If addition of correct code makes the surface manifestation unbearable (application constantly bombs), then you can restore the broken code as a temporary work-around, to be removed as soon as the bug on the other side of the interface is properly addressed.
If one side of the API knows which cases are failing on the other side, you might be able to detect the suspect case and write a record to the log file "overlapping FOO handled by dubious heuristic BAR". Then if the work-around code causes a downstream cascade of weirdness, people don't get too quick to decide that another 100 bugs need to be reported.
I've also found that conservative design and coding conventions mitigates these interdependency cascades.
It can be a good idea wading into an unstable code base to pare down to a completely stable build. This is a build where you compile out functionality until what remains is believed to be rock solid. If your rock solid build is hugely divergent from your production build, then you likely have a serious cultural or management problem.
It's almost always faster in the long run to merge solid code back into the rock solid build than jello diving on an unstable production build.
On a big project, it's great to have a couple of world class jello divers to actually get the product out the door.
It should never be half of your release team. An ecology of jello dancers tends to support only one big fish, as the Microsoft story illustrates. When half of your release team is 100 FTEs, it's amazing what you can pass off the buying public long enough to rinse and repeat.
I can also say as an architect that I'm wounded to the core if my code base degenerates into a cascade of jello dancing. More than once I've seen the exact moment where a solid code base takes a bad turn. One time I took a several weeks off due to a death in the family at a critical design juncture. Everyone worked really hard to fill in the gap, and some new features were completed in record time by bastardizing one facility to do what it hadn't been intended to do. The project lived to see another day. The software was never as solid again. It's brutally hard to back these things out.
I've also sat down to discuss implementation strategies with other developers only to discover the person was navigating around the core difficulty in the belief that he ended up with would handle 99% of the cases required by the next shipment point. The person might look at this as the difference between one day to whip it out (cue infantile jokes), instead of three days to nail the specification, at a point in the deliver schedule when days (and nights) are precious resources.
It's a false calculus once you consider the downstream investment in validating the code, shipping the code and obtaining marketplace confidence, bug reporting cycles, and the persistent niggling fear that every subtle bug "could be one of five or ten different corner cases we shaved off in the last iteration".
No large project is ever shipped without cutting corners, but you have to choose your battles carefully. If you end up with a cascade of interdependent bugs, someone along the way made some unwise choices.
By the time you are proposing to build a meta-bug tracker because these interaction chains exceed what can be mentally managed, it sounds like a invitation to a bring in an MBA student to write a case study of a business whose business model had degenerated into managing their own dysfunction. I would think long and hard about this before I mastered my queasy feeling.
KnowledgeDNA (Score:3, Informative)
Re: (Score:2)
Well, *every* bugtracker software does that, including the OSS ones.
Redmine, trac, MantisBT, googlecode, launchpad, Jira, Bugzilla, to name just a few.
It's not quite a unique selling point.
One giant Gantt Chart (Score:2)
The programmer in the back of my mind will lynch me for saying this, but this is the only way I see out of the gordian knot:
Define them all as issues in one giant project and try to map out all the dependencies.
That way, you know what bugs are awaiting what (forwards) and which bug you can work on when a certain bug was fixed (forwards).
Ths only problem is assigning the management of the chart (or parts of it).
Probably the person in charge of the team that reported the bug.
Should a bug fail to make any prog
Re: (Score:2)
Re: (Score:2)
Well, the original question was how to respond to management "how are we doing?" questions, and management likes to have expectation of time to certain goals. Of course, unless there at time commitments associated with all the bugs (many of which are external) involved, the time piece of your gantt chart is going to be a wag anyway, but if you have the kind of ma
Re: (Score:2)
Ahh, a little WAG, precision and presentation works much better than screaming "P does not equal NP".
I am not a professional programmer, I just think DAGs would work a lot better in this case where everything is external and deadlines cannot reasonably be made while relying on external resources.
Re: (Score:2)
I have to admit that I am not a professional programmer and that I have never heard of a DAG model.
I'm more of a Prince2 (project-oriented) person.
Projects tent to be defined by the fact that they have a deadline.
What most managers want to know is: will I still amke my deadline?
If something threatens that deadline, they want to be the first to know, so they can work on a (re)solution (apply pressure, different program, hire (bribe) the FOSS programmer, hire an expert, re-allocate resources, extend deadline,
Re: (Score:2)
DAG = Directed Acyclic Graph [wikipedia.org]
Re: (Score:2, Funny)
a good manager will check your plans, then quietly observe as the experts 'do their thing' and occasionally inquires to the status (AKA can I help)?
How I wish ... in the real world, there are 4 levels of bug tracking that my boss uses.
Level 1 - An email entitled "can you fix this ?".
Level 2 - An email entitled "why isn't it fixed yet ?" (which arrives 15 minutes after the Level 1).
Level 3 - An email entitled "URGENT - fix it now !!!" (complete with red exclamation mark, which arrives about an hour after the
If you can't answer (Score:3, Insightful)
"How we doin' overall" then your not managing anything.
You set goals, you set milestones to get there, and you measure according to those goals.
When they don't meet, you explain why.
Simple... (Score:4, Insightful)
I fix bugs as they are reported. There are currently 0 outstanding bugs in the various software projects that I maintain.
Re:Simple... (Score:5, Insightful)
Must not be a widely-used application then. While this approach is laudable, it's hardly sustainable for any project of substance.
Re: (Score:3, Interesting)
The most widely used application is used by thousands of people in over 50 countries. I consider it a "project of substance." :)
Re: (Score:2)
I won't say exactly what the product is, but I'll describe it. It consists of ~10k lines of code that run on a custom piece of embedded hardware plus a desktop application (to control the hardware) consisting of ~120k lines of code.
Re: (Score:3, Insightful)
Or maybe they have proper bug management, and assign the bugs based on priority and schedule impact. Why assign bugs to somebody if you know they won't be able to deal with them? They'll just end up with a huge list which won't be any help to their ability to focus on the critical issues. Yes, experienced engineers are better at managing their tasks, but it's still silly just assigning them willy-nilly as they will get lost in the system eventually.
We have at least weekly bug review boards with the produ
Re: (Score:2)
I could be wrong, but I think the person who asked this question is dealing with a situation where bugs have built up over time, and now he has to go in and clean them all out. Obviously dealing with bugs as they are reported is ideal, but not everyone finds themselves in an ideal situation at all times.
Re: (Score:2)
Bug #1.
Donna keeps bitching about my software. time to "fix her".
Bug #2.
Never mind. Eric is a quick learner. bug fixed.
Re:Simple... (Score:5, Insightful)
This doesn't scale.
Consider large-scale projects, something like the linux kernel, glibc, or X, where it is unreasonable to try and fix all bugs.
There are various reasons for this...some bugs can't be reliably reproduced so you add instrumentation to gather information when they do recur, others require months of uptime to reproduce, or special hardware/software that you don't have so it takes a long period of back-and-forth with someone that does have it.
Consider cases where you're too close to release to fix the bug "properly", so you paper over it temporarily but you want to leave a bug report open to remind you to fix it in the next release.
Re: (Score:2)
You are absolutely correct. I have the luxury of being the only person who has worked on this project since its inception 17 years ago. When a bug is reported, I can usually figure out what is causing it within 5-30 minutes. In a similar amount of time it is usually fixed.
A large multi-programmer project is very different.
The World Wide Bug Web (Score:2)
I went to a really good talk about how to use pre and post commit hooks in Trac to make other (external) events happen. Provided there's not too large a universe of bug trackets in common use out there, you could push comments into other trackers or pull related threads back into yours.
i.e. Closing the ticket when "papering over" a bug creates a new ticket to have a proper fix tagged as a requested enhancment.
i.e. If the other trackest also have a Wiki, link to the objects in your own tickets. For example,
Re:Simple... (Score:5, Funny)
a.k.a. "Look at my dick, it's enormous."
Re: (Score:2)
While true, that's not the point. ;)
The point is that a focus on writing excellent code in the first place and then fully understanding and fixing bugs when they are discovered results in a much better product. I don't think many organizations stress *fully* understanding all observed behavior.
Far too many programmers see things that make them say "huh, that's odd" and then never investigate. I'm not sure whose fault that is (the programmer's or management's) but it is a serious problem. In my 20+ years of
Re: (Score:2)
"Fully understanding something always pays off in the long run."
The managerial problem being that in the long run we all are dead and it doesn't matter.
That means that sometimes it's a better strategy not to wait for the long run to recover your pays off and avoid the expenditure right now, even if that means a dirty hack instead of a solution solidly founded on understanding.
Re: (Score:2)
I believe that "the long run" is, at most, a couple of years. If your application is a prototype, or a proof of concept, or something you are building to convince some VCs to fund your idea then you may be right.
If you are building something that will be used for many years, will evolve over those years, and must be very reliable during all of those years then I believe that the best thing to do is to have a very strict "everything must be understood" policy.
Re: (Score:2)
"If you are building something that will be used for many years, will evolve over those years, and must be very reliable during all of those years then I believe that the best thing to do is to have a very strict "everything must be understood" policy."
Your policy seems reasonable. It's only reality shows otherwise. Just two examples:
1) Facebook: they could hold till they understool what their bussiness case was, what was the best technology to achive their well understood goals, plan for hugh scalability
Re: (Score:2)
Fix them or close them as "I don't think this is a bug"?
Do you have any clueless users?
Re: (Score:2)
The problem the OP has is not with bugs in their own code, but in bugs in the code that they depend on. Their team is not (ostensibly) responsible for fixing the bugs, they just need to know when/if they are. Now, Open Source makes that more of a stretch, but it's entirely conceivable that one's software could depend on non-free code (or be built in a framework) which they have no modification ability for. At that point, it's important to be able to know the status of that that file I/O bug, or inability
Re: (Score:2)
Sorry, but "fix all submitted bugs" is just not possible, unless you are using a different definition of some of those words than everyone else. Or more likely you get a very limited set of bug reports, for whatever reason.
For a start the difference between a "bug" and a "feature" is non-existant to any normal user, so your code would have to be Skynet to not have any bugs. Also almost all users will have no idea how much work a bug entails, so you tend to have reports of "make application play alert soun
Re: (Score:2)
You are correct; I do not get bug reports directly from users. They are filtered through people who are very knowledgeable about the product. That said, any actual bug is always sent to me. I define a bug to be crashing or any obviously bad behavior as well as a feature not behaving how we claim it should. "Make application play alert sound when Foo happens" is not a bug, it is a feature request.
We get very few actual bug reports, and when we do get them I almost always fix them within a day or so of receiv
Re: (Score:2)
Because it's been a long time since my view of what a bug is would meet that definition. Almost all bug trackers have priority/severity/whatever markings ... so that the very small number of bugs that fit into your category can stand out. On all but the very worst software those are "always empty" as you describe, but they account for probably somewhere between 0.01% and 1% of the actual "bugs".
To a user everything that doesn't work as they want it to is a bug, some of the things you can easily argue are
The 2.5 I've used (Score:5, Informative)
That's just the start.
Debbugs (Score:2)
Debian's bug tracking system (see bugs.debian.org) is probably a bit difficult to learn all of the useful features it has, but I find it's one of the best. It can:
* Operate entirely by email, without needing logins and the like.
* Anyone can subscribe to any bug they find interesting.
* Users can assign any "usertags" they like to a bug, to keep track of cross-cutting concerns, or to get summaries of an arbitrary collection of bugs on one page.
* Keep track of bugs forwarded ups
Re: (Score:2)
It's probably an easy patch when debbugs is deployed at the OP's site.
Re: (Score:1)
Re: (Score:1)
Not sure the last time you used Bugzilla but you can currently track time, entering an estimated time and updating the actual time as you go.
You can also configure when you want to get emails based on what fields change and your relationship to the bug (Originator, Assignee, or watching).
Bugzilla is the only system that I have ever "liked" to work with. I have used several commercial systems as well as several large scale home grown systems over the last 20 years. All the others were slow and cumbersome a
Re: (Score:2)
Trac works pretty well as an internal bug tracking system where tight integration with the version control repository is important to you. Making it easy for tickets and commits to reference one another can be really helpful. I can't imagine it would be appropriate for the situation being asked about here though.
The current Bugzilla feature list includes time tracking; I'm curious if you tried that but didn't find it adequate, or was that just added since you last upgraded?
Re:The 2.5 I've used (Score:4, Informative)
Bugzilla has "good search features"? Whenever I try and search a bugzilla database I seem to either get 0 hits or about 8 billion. Really. It's like a magic trick or something...
JIRA is the best bug tracker out there IMHO...
Re: (Score:2)
The trouble with Bugzilla search with a large database is that you have to use the 'advanced search' to narrow your query, but you have to know alot about the product you're reporting against to use it effectively.
It would be neat if the big pile of basic search results had nice drill-down tools.
Re: (Score:2)
this isn't a bug tracker so much as a task & time tracker but I can't live without clocking it [clockingit.com] now
WTF? (Score:2)
Why the heck is your company allowing every project manager to roll their own bug-tracking system in the first place? Everyone probably has their own fscked revision control and change management packages too. Get a robust tracking system (or even a CRM system) that allows tracking of issues, bugs and changes for multiple projects all in one database. Even a small business (10-20 employees) can benefit from this kind of consolidation in the long run.
If you don't have the resources or inclination to do a con
Re: (Score:3, Insightful)
Obviously you've never worked for a ginormous corporation with competing divisions and a history of mergers stretching back a century or more. Suffice to say, it's really not that uncommon for there to be different bug tracking systems. I work for a large telecom company, and while I only work on about four or five projects, there are at least five different bug trackers, project management tools, and various other bits of e-bureaucracy that I deal with every day.
Re: (Score:2)
Why waste the human resources?
Post it notes on 32 inch TV (Score:3, Funny)
Re: (Score:2)
My question is: When did TV's ever come with a non-glossy screen?
I've tried a couple (Score:1)
The place I'm at now uses Team Foundation Studio. It works well, though might be more then a smaller shop needs. The last place I was at used trac, but AFAIK, it doesn't have a very robust method of accounting for bug dependencies.
Tasktop (Score:2, Insightful)
I use Tasktop. It is available as a standalone product or as an eclipse plug-in and will bring all the tasks from the multitude of bug trackers that I use for the various projects together so I can organize them as a todo list. So far it has worked great for me.
The second thing I like about tasktop is that it is an extension of the Mylyn project. Therefore it can limit what I see on my screen to items that are pertinent to my task, including interfacing with Firefox.
Bugzilla will be adding inter-tracker support (Score:1)
Bugzilla 3.4 will have rudimentary support for saying that a bug is related to a bug in another bug-tracker. Currently the development version allows you to input Bugzilla and Launchpad bugs, and we'll probably allow Trac and Jira in some future version, too.
Future versions will also automatically update the other bug tracker, if possible, to let them know that you've set a relationship to their bug.
The relevant bug for tracking development on this feature is here:
https://bugzilla.mozilla.org/show_bug.cgi?i [mozilla.org]
Tps reports (Score:2)
Tps reports
Bug Tracking is even worse than Version Control (Score:4, Insightful)
Why can't anyone agree one what's "right to use"? It seems everyone and their dog has a bug tracker, and I've yet to see one that seemed to do its job "well". Is this something that has a secret really elegant solution that Linus can pull out of his ass in an afternoon and save us all?
I wouldn't expect it, since he uses /mailing lists/ of all things, to track things. I suppose it's sortof a decentralized model of bug tracking: everyone has to figure shit out for themselves.
If I don't see an easy way to note:
- A list of known issues
- Whether they're being worked on by anyone
- What I can do to help
- What the plans are for the future
I'm much less likely to like a project. Having to send an e-mail requesting these things on a case-by-case basis seems just plain stupid.
Perhaps some elegant solution is there somewhere, begging for someone to bring it to light. Just as git accepted that e-mailed patches would always be essential to any project which used version control, maybe something can be built which rests on top of a simple mailing list, and takes care of the history and classification which is the true purpose of issue tracking.
The best system of any sort is one which not everyone needs to actively use for anyone to get benefit from.
Re: (Score:3, Insightful)
Because its a multidimensional, subjective thing so, for any given person, there won't be one clearly superior product, and no two people will be guaranteed to have the same preferences.
What would be nice (and facilitate the kind of cross-tracker tracking that OP seems concerned about) would be some kind of least-common-denominator communication protocol and issue data format so that even if everyone isn't using the same tool, its possible to do basic centra
Re: (Score:2)
One project that really seems like it is going in the right direction is Ditz [rubyforge.org], a decentralized issue tracker. Now that decentralized version control is becoming popular, there are a handful of decentralized issue trackers being built (other are cil, git-issues, and others whose names escape me). None seem to be very usable yet, and all are experimenting on what works best.
If you are looking for some kind of git-like breakthrough in bug tracking, that's where I would look.
Humans and feet (Score:2)
Most bug tracking software can do dependent links or related bugs. But when it comes down to it you have to use your feet and go walk over to people and actually talk to them if your stuff needs fixing. By going around and chatting with people you're dependent on you'll always have a sense for what's going on and when management comes to ask you can stop staring at your gum-filled shoes and give 'em a straight answer. :)
Neil
Extension addressnig (Score:3, Informative)
Why not use plus addressing to map any outside correspondence about
the status of your external bug to one in your internal tracker?
This presumes the outside project has a sane system, and may require
a separate account for every bug though. Many similar possibilites
exist e.g; maintain a table for your mail daemon to the mapping
rather than using accounts to do so.
If you've got issues, try JIRA! (Score:2, Informative)
Debian's solved this (Score:2)
Debian's bug tracker deals with this well. It understands many different types of bug trackers - IIRC, among them launchpad, bugzilla, trac. If a bug is opened with Debian, it can be forwarded upstream, and when it's resolved, Debian's bug tracker will mark it as 'resolved upstream', and it can be closed when a package with the fix is uploaded.
Changing it every 6 months doesn't work (Score:2)
PostIt Notes? Go digital (Score:2)
Well, I can do a little better than that (if not much). I keep a folder full of bookmarks to the URLs of reports I've filed in external trackers.
And of course, most trackers send you email when things change.
This has worked for me, but I only track a half dozen bugs at a time, a far cry from the 200 mentioned in TFS.
Anything BUT 'Trac' (Score:2)
Re: (Score:2)
"Whatever you choose--please do not let it be Trac, which is a piece of garbage. Go ahead and try to install and maintain it: I dare you. What a mishmash of bizarre pieces of other crap bolted together."
I do. It was just installing, about half a day to mildly understand its underpinnings and except for the odd "can you please add a new component" zero maintenance. It is not that it's perfect (it's focused on the "technical" side forgetting totally about the "managerial" part and, of course, it's unability
Re: (Score:2)
Re: (Score:2)
You may want to take a look at redmine which many consider to be "trac done right".
Distributed? (Score:2)
Probably the biggest irritation for me wasn't figuring out which bugs depend on which -- I'd always have some I know I have to work on. Bugs blocking anything critical get bumped up in priority, so I, as a programmer, don't have to think too hard.
So, sure, a dependency system would be great. Trac-style linking is essential, anyway, for humans to refer to one commit or another.
But, what's been interesting me lately are things like Ditz, which stores issues as yaml files which can be easily managed through ve
Re: (Score:2)
Main reason I prefer Ditz is that it's written in Ruby. And as I've already needed to extend it, I can say with some confidence that this actually matters. Not that Python is bad, I just prefer Ruby, and I'm a language snob.
Also, a quick glance at the BE webpage:
Supported version control backends: Arch, Bazaar, GIT, Mercurial, RCS
Ditz just uses plain Yaml. It is completely VCS-agnostic. You can add hooks to auto-add/commit, to make life easier -- these are trivial, only a few lines of code to implement. But they aren't required at all.
Perhaps BE is like this, but the mention
Rational Suite (Score:2)
- Severity tracking: categorize or re-categorize your bug according to severity
- Source control integration: link your bug directly to one or more source files with a direct link to ClearCase (the sister Rational application...highly recommended)
- Authentication plugins: standalone database (DB2 UDB) or LDAP/AD
- Authorization: fine grained, with approvers list and list of team
Some rational tool (Score:2)
At my first job, we used some Rational tool to manage our bugs... I forget the name of it, but it got the job done. Where I work now, we use Bugzilla. I think Bugzilla has some room for improvement, but it gets the job done.
My real issue with how my company uses Bugzilla is that if I don't work with it all day long; I really don't understand the conventions in place needed for the proper workflow. I don't think this is a technological problem, as any collaboration application used by a lot of people wil
rt3, or Request Tracker (Score:2)
I'm a big fan of rt3 ( http://bestpractical.com/rt [bestpractical.com] ).
Pros:
- Free and open source
- Web, email, and command line interface
- Flexible (I've used for bug tracking, support departments, task and project management, documentation, mailing lists, and more)
- Scalable (I've seen it go beyond 100,000 tickets on an average server with no performance hit)
- Excellent community (mailing lists, wiki, book, contrib section on the site)
Cons:
- Written in Perl, so its a bit tricky to configure and customize
Give it a try.
Re: (Score:1)