3 ms·

> 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? Do

> 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 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.

quietbritishjim 1y ago
> > 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" (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.
- crabbone 1y ago
  > They just said that the bug number was enough to "to tie the two together". 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.
  - Joker_vD 1y ago
    And the other is the bug, whose number is being include in the commit message. So the commit is tied to the bug it addresses (whatever "addresses" may mean) by including the ID of that bug in the commit message. Also, just to clarify, you can have several commits that refer to the same bug, and also commit message may (and likely should) contain some other text in addition to the bug number.
    - crabbone 1y ago
      But, like I mentioned above: bugs have many properties, can be grouped permanently or ad hoc... you either need to label the connection you make between the commit and the bug, or have bug modalities, otherwise these connections become meaningless / useless. To flesh it out, let's suppose this (uninvented scenario, I literally opened JIRA on the last ticket I worked on, it's called "Jupyter wizard" and has to do with a TUI utility that allows one to configure Jupyter installation). There are multiple people interested in this ticket who work on the source code: * QA tester (needs to verify multiple features of the wizard). * QA manager (needs to know the status of testing / communicate to the tester). * R&D programmer (needs to write the code for TUI). * R&D manager (needs to supervise the programmer). Optionally, of course, the head of the R&D department and anyone under him / her might want to look at the issue and contribute as well as release manager, product manager, customer support... All the people involved have a reason to tie different commits to this issue. The tester may add a new test checking whether users can install VNC for Jupyter. The QA manager may annotate the added test to be included in nightly CI runs. The programmer may add code that breaks the test and the programming manager may add code to hide the newly added feature behind a feature flag in order to prepare the code for the upcoming release. If all these people will only be able to say "commit" x "ticket", then for everyone involved there will be a lot of white noise when they try to discover the relevant work done on the feature. In fact, it will be so much, that such pairing will become meaningless because the team across the hall will also refer to this issue because they are writing the TUI library to be used in wizards, the customer support will request documentation for the feature and documentation writer will have to add more commits, again, referring to the ticket, producing multiple versions of the said documentation conditioned on release version... In the same way how JIRA asks users when linking tickets together: how they should be linked, the commits and tickets also need to be linked in different ways to explain the nature of the relationship.

quietbritishjim 1y ago

> > 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" (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.

crabbone 1y ago
> They just said that the bug number was enough to "to tie the two together". 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.
- Joker_vD 1y ago
  And the other is the bug, whose number is being include in the commit message. So the commit is tied to the bug it addresses (whatever "addresses" may mean) by including the ID of that bug in the commit message. Also, just to clarify, you can have several commits that refer to the same bug, and also commit message may (and likely should) contain some other text in addition to the bug number.
  - crabbone 1y ago
    But, like I mentioned above: bugs have many properties, can be grouped permanently or ad hoc... you either need to label the connection you make between the commit and the bug, or have bug modalities, otherwise these connections become meaningless / useless. To flesh it out, let's suppose this (uninvented scenario, I literally opened JIRA on the last ticket I worked on, it's called "Jupyter wizard" and has to do with a TUI utility that allows one to configure Jupyter installation). There are multiple people interested in this ticket who work on the source code: * QA tester (needs to verify multiple features of the wizard). * QA manager (needs to know the status of testing / communicate to the tester). * R&D programmer (needs to write the code for TUI). * R&D manager (needs to supervise the programmer). Optionally, of course, the head of the R&D department and anyone under him / her might want to look at the issue and contribute as well as release manager, product manager, customer support... All the people involved have a reason to tie different commits to this issue. The tester may add a new test checking whether users can install VNC for Jupyter. The QA manager may annotate the added test to be included in nightly CI runs. The programmer may add code that breaks the test and the programming manager may add code to hide the newly added feature behind a feature flag in order to prepare the code for the upcoming release. If all these people will only be able to say "commit" x "ticket", then for everyone involved there will be a lot of white noise when they try to discover the relevant work done on the feature. In fact, it will be so much, that such pairing will become meaningless because the team across the hall will also refer to this issue because they are writing the TUI library to be used in wizards, the customer support will request documentation for the feature and documentation writer will have to add more commits, again, referring to the ticket, producing multiple versions of the said documentation conditioned on release version... In the same way how JIRA asks users when linking tickets together: how they should be linked, the commits and tickets also need to be linked in different ways to explain the nature of the relationship.