Re: Any concrete plans after the GDB BoF?

> > 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.
> 
> Whether the commit should be reformatted and auto-approved is orthogonal
> I think to whether we should have an auto-format checked as part of the
> commit hook.
> 
> As long as folk are able to manually push to master then the process is
> open to (honest) user mistakes, and we should, as far as possible aim to
> have systems in place to guard against those mistakes.
> 
> So having git refuse to accept a commit that is incorrectly formatted
> would be a good thing; though I 100% agree with you that ideally we
> would ALSO have tools that could auto-check the formatting earlier in
> the process and bring that to the developers attention.

Agreed. If we want to ensure correct formatting, we need to check for it
before the commit gets pushed. The earlier, the better.

> > 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'd avoid the word 'antiquated' as it (too me) seems to have negative
> connotations.

I agree with that, and was only using this word in the context of
me putting myself in the shoes of those who shared this feedback
with me. Personally, I love email. But truly, some of the younger
generation I talked to simply do not understand our reluctance to
switch to what they believe to be superior technology. As far as
code collaboration goes, they truly see email as a thing of the past.

Having gone through a transition from email-based review to reviews
through a dedicated system, I have to say that it hurt at first,
but generally speaking, I think it was a huge boost overall.

> But I agree, many developers are familiar with a pull-request
> development model, and I think it has many advantages over our current
> way of doing things, I'd be very much in favour of switching to a PR
> style system.
> 
> That doesn't mean there aren't also advantages to how we do things
> today.

Agreed also.

-- 
Joel