On Tue, 9 Jun 2009, Ian Lance Taylor wrote: > I believe that the most useful immediate thing we could do to speed up > gcc development would be to move to a distributed version control > system.
We haven't even finished the last version control system transition (wwwdocs is still using CVS), it's not long since we started it and there is as yet no one clear winner in the world of DVCSes, so another transition would seem rather premature. > That should make it much easier for people to swap patches > around. I don't see what the present difficulty here is supposed to be. For small to moderate-sized self-contained patches the precise system used makes little difference. For large to huge patch series from contributors with write access, they are already able to create whatever branches they may wish. Distributed systems would facilitate large series from contributors without write access, but in practice I think such contributions from non-regular contributors tend to run into other unrelated issues (and hosting a public tree the size of GCC isn't really something to consider "easy" whatever system is used). > It should make it possible for reviewers to take a patch, make > some changes themselves, and send it back to the original submitter for > more work. This is already possible, but I don't think difficulties with it are a significant problem with patch review at present. If the original submitter is to submit further patches then having them understand the deficiencies enough to fix them themselves is generally better than fixing them for them. (The simpler case of fixing the submitted patch and committing the fixed version is already quite common.) > It would make it much simpler for people to reliably test > other people's patches, singly or in combination. As I observe it difficulties in dealing with other people's patches arise not because of version control choices but because of interactions between logical changes expressed textually in patches, especially global mechanical changes, and semantic patch tools seem to me to be more promising to help in such areas. I have observed patch review and its failures in action through following the main GCC lists since the start of EGCS. It's not the large and complicated patches than in my experience have difficulty getting reviewed; those generally come from people with extensive experience of GCC development, and if those people cannot approve their own patches there are other people with sufficient interest in them who do so. It's smaller patches, and patches from outsiders, that have the greater difficulty, while it's complicated patches from sophisticated developers that more advanced version control systems help more with. If a patch does not attract the interest and attention of reviewers when posted, there is no system (human or technical) to notice this and to track that it still needs review and who might be a suitable reviewer, other than the submitter pinging it. If a patch is submitted by an outsider who hasn't followed all the documentation on submitting patches, and may not have properly tested it, or described how it was tested, or written a proper ChangeLog entry, or formatted it according to the coding standards, or followed the correct abstractions, the fact it doesn't look like a normal submission and requires greater effort to review makes it less likely to be reviewed. If a patch from an outsider is nevertheless approved, the approver will typically say it is OK, and it will be up to the outsider to reply that they don't have write access and get someone to commit it. At the human level I suspect it would help to have people who watch for submissions from non-regulars (including those attached to Bugzilla) and help them prepare patches following all the usual conventions and get them reviewed (checking for copyright assignments at an early stage as needed) and make sure the submissions don't get lost. At the technical level, while submissions on gcc-patches take a wide variety of forms, approvals are more restricted; it ought to be possible for software to do a reasonably good job of tracking which submissions have been reviewed / approved / committed (including noticing people trying to submit patches through Bugzilla), and of identifying the most likely relevant maintainers to review patches, aided by humans in keeping the data clean. -- Joseph S. Myers jos...@codesourcery.com
