11–20 of 29 posts
I would differ from the author on the need for tight coupling to source control. There could be any number of folks who want to see what's going on with an item but have no interest in or even understanding of the actual related code. It's easy enough to include a bug number in commit messages to tie the two together.
Earlier quoted context omitted.
“badly broken but doesn’t matter”?
A totally broken function that a single person uses once a month to save five minutes isn't nearly as valuable as a well-designed feature that 5,000 users rely on daily to save just one minute each session.
I believe the principles the article author is looking for are core to Pivotal Tracker. I've often tried to persuade teams to use Tracker, but everyone sure loves the whiteboard metaphor!
Unfortunately, Pivotal Tracker was decommissioned on April 30, 2025. It's dead and gone. Related HackerNews discussion: https://news.ycombinator.com/item?id=41591622
In true pivotal tracker spirit their mobile apps are terrible, but perhaps that’s for the best.
With popularity of myriad of development methodologies there was DDD, Debug Driven Development. You start a project by filing the first bug: "The app shouldn't be blank."
How would you debug that, tho?
Loved Bugzilla back in the '00s. Used it just as the author described: everything was a bug. New features, enhancements, actual bugs/problems. Worked very well. I would differ from the author on the need for tight coupling to source control. There could be any number of folks who want to see what's going on with an item but have no interest in or even understanding of the actual related code. It's easy enough to incl…
No. This is absolutely not enough. Does the commit resolve the issue? Does it add a test to the issue? Does it disable the buggy feature?
Also, I'm of an opinion that if you are hired to work in software development company, you need to learn how to use version control. Just suck it up, if you don't like it. No excuses. Version control is the protocol for sharing information, especially useful because it's understood by the "grunts" actually creating the product. If a manger doesn't understand this language he or she will be as useless as a manager who doesn't speak any natural language his or her team speaks.
In general, from the QA perspective, QA wants to know a lot more about the connection between the bug and the source code. It may ask questions s.a. "What general group of issues is affected by the change?" or "Is this a work-in-progress kind of change?" or "Does this change affect the performance of the system?" or "Is this change known to affect another change, perhaps these changes are mutually exclusive?" or "Is this change intended for a particular release of the product?". This and similar information is necessary for QA to minimize the number of useless tests to run, to minimize the number of pointless alerts, to have a hope of producing reliable metrics that show overall product quality level increase / decrease.
Loved Bugzilla back in the '00s. Used it just as the author described: everything was a bug. New features, enhancements, actual bugs/problems. Worked very well. I would differ from the author on the need for tight coupling to source control. There could be any number of folks who want to see what's going on with an item but have no interest in or even understanding of the actual related code. It's easy enough to incl…
> It's easy enough to include a bug number in commit messages to tie the two together. No. This is absolutely not enough. Does the commit resolve the issue? Does it add a test to the issue? Does it disable the buggy feature? Also, I'm of an opinion that if you are hired to work in software development company, you need to learn how to use version control. Just suck it up, if you don't like it. No excuses. Version con…
> No. This is absolutely not enough. Does the commit resolve the issue? Does it add a test to the issue? Does it disable the buggy feature?
They just said that the bug number was enough to "to tie the two together". They didn't claim that was all that the commit message can or should say. For example, "added tests for #24" (followed by some details) would follow that template.
> Also, I'm of an opinion that if you are hired to work in software development company, you need to learn how to use version control. Just suck it up, if you don't like it. No excuses. Version control is the protocol for sharing information, especially useful because it's understood by the "grunts" actually creating the product. If a manger doesn't understand this language he or she will be as useless as a manager who doesn't speak any natural language his or her team speaks.
This is ludicrous. The point of version control is to understand the way that the source code changes. Managers do not need to understand the software at that level of granularity, that is our job as software developers. Issue trackers are a much better fit for that.
Earlier quoted context omitted.
> It's easy enough to include a bug number in commit messages to tie the two together. No. This is absolutely not enough. Does the commit resolve the issue? Does it add a test to the issue? Does it disable the buggy feature? Also, I'm of an opinion that if you are hired to work in software development company, you need to learn how to use version control. Just suck it up, if you don't like it. No excuses. Version con…
> > It's easy enough to include a bug number in commit messages to tie the two together. > No. This is absolutely not enough. Does the commit resolve the issue? Does it add a test to the issue? Does it disable the buggy feature? They just said that the bug number was enough to "to tie the two together". They didn't claim that was all that the commit message can or should say. For example, "added tests for #24" (follo…
What's the other one they are tying together? Presumably the first one is the commit...
> This is ludicrous. The point of version control is to understand the way that the source code changes.
No it's not. This is why version control exists in programs that generally don't deal with code, s.a. Microsoft Word for example.
In not so many words: Gitea bug tracking ability is poor. The author improved it a little bit, but still not enough for it to be good.