code review metadata & comments should have been baked into distributed version control systems from the start and now we get to pay for this mistake forever.
(let's throw issue tracking in there while we're at it.)
the point here being not that one single piece of software needs to do all this stuff, but rather that the data is so integral to what a piece of code _is_ (just like the history!) that capturing it has effectively foreclosed most of the possibilities of the dvcs as an escape valve from monopoly control over the software development platforms.
you should, ideally, be able to treat code hosting and the VCS format itself as a simple pipe between whatever tooling suits your purposes. instead... well, here we are.
@brennen agreed. I think you could say this is an important part of a larger problem, that git et al have specific use cases baked in
@brennen the Linux kernel folks on the whole don't seem to believe in tool support for keeping track of bugs, or even in keeping honest history about how development actually happened (cf the concept of the "perfect patch"). I honestly believe the Linux kernel developer mindset is to throw away any information that suggests things were ever not perfect
@clacke @brennen I agree that both views are useful. I was going to say more but then I realized I've already said everything I would have, here: https://jamey.thesharps.us/2016/05/19/perspectives-on-commit-history/
To your points, I think I particularly want to emphasize where I wrote that "we shouldn’t design our processes around the UX failures of our tools if we can just fix the tools instead."
(The first blog link from that post is broken; it should now go to https://sage.thesharps.us/2013/05/08/patchsets-for-dinner/ )
> Ideally you'd have both. I would love for a PR to be merged as a neat squashed commit or tidy merge, with the messy history as a second parent
i've been using gerrit at work for some time now, which has been a window into just how nice carefully authored units of history can be, and in fact offers something like this: changes are a single commit, but you can if needed go back and find all the patchsets that they were assembled from.
@brennen @clacke @jamey Possibly relevant: https://blog.digital-scurf.org/posts/bookclub-20200511/
@brennen I'd like to think it's not necessarily too late. And there exists at least one example of tooling like this already (fossil), but yeah, we're all well and truly captured by chains of our own making. And it's not just tools. It's our institutions and the values we decide they should stand for. It was interesting to watch Python just slide over to GitHub because it revealed a little about the values of the institution.
I know you're actually talking about the systemic issue of nobody having had something like this available (or a number of other things) and how that's affected running projects up to now
but, there are apparently already ways to keep issues in a repository,
and I've been considering a project to try to integrate one with #gitea
there seem to be a number of people who want this, so even if I don't get far i'd assume others will be trying similar things
@brennen "but brennen," a voice from no where says, "don't you agree, that worse is better?"
@brennen "having something, even if it only implements part of the solution surely beats having nothing"
sweeps darcs and fossil under the carpet
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!