Hi Joseph, On Thu, 2024-04-18 at 15:56 +0000, Joseph Myers wrote: > On Thu, 18 Apr 2024, Mark Wielaard wrote: > > > But we like to get more feedback on what people really think a > > "pull-request" style framework should look like. We used to have a > > gerrit setup which wasn't really popular. And we already have a > > sourcehut mirror that can be used to turn your "pull-requests" into a > > git send-email style submission (without having to setup any > > email/smtp yourself): https://sr.ht/~sourceware/ > > The xz backdoor showed up one issue with some implementations of > pull-request systems: GitHub removed access to the repository, and with it > access to the past pull requests, so disrupting investigation into the > sequence of bad-faith contributions.
Agreed. I tried to analyze the valgrind issues after the fact (we clearly missed them before, there were warning, but they were fixed so quickly we didn't really look into them as we should have). And it was a bit difficult because the github repository had disappeared. But luckily the project did have a "real" git repo: https://git.tukaani.org/ This obviously didn't contain any "pull requests" but I am not sure they were used on the xz github mirror. Does github require pull requests to keep around? What if someone closes/removes their own fork/repo/account, do the commits transfer to the project? > I suggest that a basic principle for > such a system is that it should be *easy* to obtain and maintain a local > copy of the history of all pull requests. That includes all versions of a > pull request, if it gets rebased, and all versions of comments, if the > system allows editing comments. So in a somewhat crude form we now have that with our email workflow. In theory every patch is posted and reviewed on one of the patches mailinglists and the public-inbox instance at https://inbox.sourceware.org/ allows you to git clone the whole archive for local inspection. > A system that uses git as the source of > truth for all the pull request data and has refs through which all this > can be located (with reasonably straightforward, documented formats for > the data, not too closely tied to any particular implementation of a > pull-request system), so that a single clone --mirror has all the data, > might be suitable (people have worked on ensuring git scales well with > very large numbers of refs, which you'd probably get in such a system > storing all the data in git); Yes, git is pretty nice for storing lots of variants of somewhat identical sources/texts. But this also seems to imply that when we offer a system to store "contributor" git trees/forks of projects to easily create "pull requests" then we can never remove such users/forks and must disallow rebasing any trees that have been "submitted". That can probably be done, but it is different from what we now require from user or devel branches in our git repos. Where we do allow users to delete their branches and devel branches can be rebased. Should such branches also become "immutable"? Cheers, Mark
