3 ms·

Initial versions, and the review comments that led to their abandonment, can be saved in your code review system.

by jefftk 6y ago

WorldMaker 6y ago
What if you need to change code review systems? Do you just abandon all that information? What if your code review system becomes a central point of failure for information that you need about your process/workflow? To use a DVCS in a distributed fashion, doesn't it make more sense to store that data in the DVCS itself?
- jefftk 6y ago
  > What if you need to change code review systems? Do you just abandon all that information? You choose one of: (a) migrate the data, (b) leave the old system running, (c) archive the data. Same as if you need to change version control systems, or any other important system. > What if your code review system becomes a central point of failure for information that you need about your process/workflow? Could you elaborate? I thought we were talking about needing to answer questions like "what were they thinking when they decided to make a specific change, at a level of detail too fine for the change description?" What would be critical to your workflow, but only available in past review discussions? > To use a DVCS in a distributed fashion, doesn't it make more sense to store that data in the DVCS itself? Nowhere I've worked has used the version control system in a distributed way, beyond someone being able to work while they're on their laptop without wifi.
  - WorldMaker 6y ago
    > Could you elaborate? I thought we were talking about needing to answer questions like "what were they thinking when they decided to make a specific change, at a level of detail too fine for the change description?" What would be critical to your workflow, but only available in past review discussions? Those discussions are an "oral history" of the project. While we may hope for 100% documentation, it isn't uncommon that everything from implicit best practices to "hidden" decision processes to even customer complaints only ever get recorded in code reviews. "Why did we decide to do it this way?" is often the most common question for an archeology dig, and the answer sometimes is critical to a given workflow. If you want to fix the bug without breaking the user scenario that introduced the bug, that can be very important information to have. > Nowhere I've worked has used the version control system in a distributed way, beyond someone being able to work while they're on their laptop without wifi. So? Just because few do it today or think they "need" to do it other than what they believe to be rare offline scenarios, implies it isn't work striving for more distributed systems as an ideal?
    - jefftk 6y ago
      > it isn't uncommon that everything from implicit best practices to "hidden" decision processes to even customer complaints only ever get recorded in code reviews That sounds like something to fix. If something is important enough that people will want to know it when working on the code later, it belongs in either a comment or a change description. When I have to reference old code review discussions it is extremely helpful to have them, but ideally you do need them only very rarely. We both recognize that these are valuable, where we differ is that I don't think they are so valuable that they need the kind of uptime you get from including them in a DVCS. > striving for more distributed systems as an ideal? Yes, I don't think this is very important. If it later becomes important it would be reasonable to integrate it into the DVCS.
      - WorldMaker 6y ago
        > If something is important enough that people will want to know it when working on the code later, it belongs in either a comment or a change description. Which is indeed what I'm arguing for. I think a lot of what gets done in code review should be directly reflected in the source control change comments. So much to the point that I think a good code review system should be not much more than a thin veneer over a commit log. I agree it's probably a distinction of degree where we disagree. I think the goal of a source control system is to encode source changes in all their forms (including reviews/revisions). Whether or not that is for DVCS "uptime", I see pushing things to an exterior code review system, at least to me, seems a failure in your source control system (or your usage of a source control system), because I see it as such a fundamental part of what constitutes "source control". Git's DAG as it exists already provides a lot of tools to give both "shallow visualizations" at a high level and "deep visualizations" into more complicated back-and-forth processes such as code reviews. Rather than solve these "visualization problems" by outsourcing components of it to external systems, I'd rather see that invested into the DVCS itself and/or the tools we use with the DVCS. (To some extent I think the tools are already there for git, they just have the wrong defaults to encourage more general usage of the DAG to communicate than a lot of projects tend to use.)

Initial versions, and the review comments that led to their abandonment, can be saved in your code review system.

by jefftk 6y ago

Initial versions, and the review comments that led to their abandonment, can be saved in your code review system.

What if you need to change code review systems? Do you just abandon all that information? What if your code review system becomes a central point of failure for information that you need about your process/workflow? To use a DVCS in a distributed fashion, doesn't it make more sense to store that data in the DVCS itself?

jefftk 6y ago
> What if you need to change code review systems? Do you just abandon all that information? You choose one of: (a) migrate the data, (b) leave the old system running, (c) archive the data. Same as if you need to change version control systems, or any other important system. > What if your code review system becomes a central point of failure for information that you need about your process/workflow? Could you elaborate? I thought we were talking about needing to answer questions like "what were they thinking when they decided to make a specific change, at a level of detail too fine for the change description?" What would be critical to your workflow, but only available in past review discussions? > To use a DVCS in a distributed fashion, doesn't it make more sense to store that data in the DVCS itself? Nowhere I've worked has used the version control system in a distributed way, beyond someone being able to work while they're on their laptop without wifi.
- WorldMaker 6y ago
  > Could you elaborate? I thought we were talking about needing to answer questions like "what were they thinking when they decided to make a specific change, at a level of detail too fine for the change description?" What would be critical to your workflow, but only available in past review discussions? Those discussions are an "oral history" of the project. While we may hope for 100% documentation, it isn't uncommon that everything from implicit best practices to "hidden" decision processes to even customer complaints only ever get recorded in code reviews. "Why did we decide to do it this way?" is often the most common question for an archeology dig, and the answer sometimes is critical to a given workflow. If you want to fix the bug without breaking the user scenario that introduced the bug, that can be very important information to have. > Nowhere I've worked has used the version control system in a distributed way, beyond someone being able to work while they're on their laptop without wifi. So? Just because few do it today or think they "need" to do it other than what they believe to be rare offline scenarios, implies it isn't work striving for more distributed systems as an ideal?
  - jefftk 6y ago
    > it isn't uncommon that everything from implicit best practices to "hidden" decision processes to even customer complaints only ever get recorded in code reviews That sounds like something to fix. If something is important enough that people will want to know it when working on the code later, it belongs in either a comment or a change description. When I have to reference old code review discussions it is extremely helpful to have them, but ideally you do need them only very rarely. We both recognize that these are valuable, where we differ is that I don't think they are so valuable that they need the kind of uptime you get from including them in a DVCS. > striving for more distributed systems as an ideal? Yes, I don't think this is very important. If it later becomes important it would be reasonable to integrate it into the DVCS.
    - WorldMaker 6y ago
      > If something is important enough that people will want to know it when working on the code later, it belongs in either a comment or a change description. Which is indeed what I'm arguing for. I think a lot of what gets done in code review should be directly reflected in the source control change comments. So much to the point that I think a good code review system should be not much more than a thin veneer over a commit log. I agree it's probably a distinction of degree where we disagree. I think the goal of a source control system is to encode source changes in all their forms (including reviews/revisions). Whether or not that is for DVCS "uptime", I see pushing things to an exterior code review system, at least to me, seems a failure in your source control system (or your usage of a source control system), because I see it as such a fundamental part of what constitutes "source control". Git's DAG as it exists already provides a lot of tools to give both "shallow visualizations" at a high level and "deep visualizations" into more complicated back-and-forth processes such as code reviews. Rather than solve these "visualization problems" by outsourcing components of it to external systems, I'd rather see that invested into the DVCS itself and/or the tools we use with the DVCS. (To some extent I think the tools are already there for git, they just have the wrong defaults to encourage more general usage of the DAG to communicate than a lot of projects tend to use.)