3 ms·

> it isn't uncommon that everything from implicit best practices to "hidden" decision processes to even customer complaints only ever get recorded in code revie

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

by jefftk 6y ago

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