Liliana Marie Prikler <liliana.prik...@gmail.com> writes:
>> one fundamental issue with the email based workflow is that its >> underlying data model simply does not formally encode enough >> information to be able to implement a slick workflow and frontend. >> e.g. with a PR based model the obsolete versions of a PR is hidden >> until needed (rarely). the email based model is just a flat list of >> messages that includes all the past mistakes, and the by now >> irrelevant versions. > What the? If anything, emails are like a tree and discussions in most > forges are a single long list that's rarely well organized. Virtually > every mail client supports threads, whereas a certain one of the more > popular forges still refuses to do so. Hiding obsolete versions of a > pull request is in practice implemented either by pushing more commits > on top of the existing one, often with dubious commit messages or by > force-pushing a branch, neither of which is an acceptable solution for > Guix. I often have to review Github Pull Requests, and I don’t go commit by commit by go through the diff and annotate the changes. I *read* the commits to get a sense for how the feature evolved and why changes were made, but the fact that new commits are pushed on top of the branch is not an obstacle in practice, because the commits don’t matter. (I know, it hurts me too, but I don’t make the rules, okay?) And in these review interfaces we can mark individual comments as resolved. So the flat list of changes with annotations *does* in fact provide a clearer organization than a tree of emails. Note also that we don’t usually review commits by starting one new thread for each issue we address, so we don’t benefit from automatic branching of sub-discussions. On Github, Pull Request branches are like our WIP branches. They are how we arrive at acceptable changes. Picky people like me would then go back and write new atomic commits for the effective diff, but in my role as a reviewer I usually rebase, squash, and merge. This workflow is more familiar to some and alienating to others, but both of these workflows would work fine for Guix. But today our tools can only accommodate *one* workflow. It happens to be the one I’m used to, but let’s please not pretend that it’s inherently *better* than the other. -- Ricardo FWIW: Mumi is the worst of both worlds as it flattens the email tree while not providing any of the review features that popular forges have. So the problem of outdated and repeated mistakes in a flat list becomes more pronounced there.
