Re: Any concrete plans after the GDB BoF?
Joel Brobecker via Gdb <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <[email protected]> |
> > Now, where this might save time is if we had some kind of git hook which > > could validate the code was formatted correctly and reject push attempts > > if they are not formatted. Then I could stop thinking about > > formatting. But until then .... I don't think reviewers will be able to > > stop asking: is this formatted correctly? > > > > That's what I have in mind. Some pre-commit hook that checks/does > things. Obviously we're not there yet, but that would be the most > convenient way. > > I think anything that needs to be checked by hand wouldn't be an > improvement compared to the current process. As long as the the tool is able to do the formatting of a given file using only that one file, the git-hooks are ready. There is a style_checker option which is currently calling a script that does nothing. But if we have some tools that check things such as formatting, copyright header format, etc, it's easy to insert them and reject the commit. The problem is that this arrives too late in the process, IMO, because by then, the review has already gone through. For a formatting issue, one could argue that the change is trivial, and therefore automatically re-approved, but this is not ideal. What we would want is some kind of CI system which, from the moment the developer proposes a patch, gets the change validated through the CI. Style-checking is usually quick, so a good candidate for a CI. But how to integrate that without starting to re-invent one of those existing Git review or Git hosting systems that already exist? What this discussing is showing, IMO, is that the email-based system of proposing and reviewing patches may be fast and comfortable, but has some limitations compared to other more modern systems that seem hard to overcome. We can find technical solutions that overcome those issues, but each time I try this exercise, I find myself thinking the problem has already been solved is there for the taking if only we could accept email-based workflows might be degraded, possibly to the point where it becomes more productive to use the recommended interface (e.g. website). Good or bad, my concern is that the younger generation views emails as antiquated and at the same time they have grown up learning about collaboration using systems such as GitLab or GitHub. I apologize for widening the discussion from code formatter to review system. It's not how I planned this message when I started replying, but it seemed natural to add the comment about how we manage patch submissions and how we do reviews. -- Joel