public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Andrew Burgess <aburgess@redhat.com>
Cc: Joel Brobecker <brobecker@adacore.com>,
	Luis Machado <luis.machado@arm.com>,
	Mark Wielaard <mark@klomp.org>, Simon Marchi <simark@simark.ca>,
	Simon Marchi via Gdb <gdb@sourceware.org>
Subject: Re: Any concrete plans after the GDB BoF?
Date: Thu, 16 Feb 2023 08:14:30 +0400	[thread overview]
Message-ID: <Y+2tppd4SjKGksWY@adacore.com> (raw)
In-Reply-To: <87zg9fkmt4.fsf@redhat.com>

> > 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

  reply	other threads:[~2023-02-16  4:14 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-27 10:47 Luis Machado
2022-10-28 16:16 ` Simon Marchi
2022-10-28 16:51   ` John Baldwin
2022-10-28 16:54     ` Simon Marchi
2022-10-31  9:28   ` Luis Machado
2022-10-31 13:17     ` Simon Marchi
2022-10-31 13:37       ` Joel Brobecker
2022-10-31 14:15         ` Simon Marchi
2022-10-31 17:31           ` Joel Brobecker
2023-02-11 17:13           ` Andrew Burgess
2023-02-12 12:43             ` Mark Wielaard
2023-02-13 11:54               ` Andrew Burgess
2023-02-13 12:52                 ` Luis Machado
2023-02-13 14:24                   ` Tom Tromey
2023-02-13 14:42                     ` Luis Machado
2023-02-13 15:13                   ` Andrew Burgess
2023-02-13 15:23                     ` Luis Machado
2023-02-14  5:48                       ` Joel Brobecker
2023-02-15 14:47                         ` Andrew Burgess
2023-02-16  4:14                           ` Joel Brobecker [this message]
2023-02-16  9:51                           ` Mark Wielaard
2023-02-16 10:16                             ` Joel Brobecker
2023-02-16 11:58                               ` Eli Zaretskii
2023-02-16 13:31                                 ` Joel Brobecker
2023-02-16 15:23                                   ` Eli Zaretskii
2023-02-14 13:07                   ` Mark Wielaard
2023-02-14 14:23                   ` Pedro Alves
2023-02-14 13:00                 ` Mark Wielaard
2023-02-15 14:36                   ` Andrew Burgess
2023-02-13 14:05             ` Tom Tromey
2022-12-15 10:17     ` Luis Machado
2023-01-01 22:02     ` Mark Wielaard
2023-01-20 17:30       ` Tom Tromey
2023-01-20 20:30         ` Tom Tromey
2023-01-27 15:50           ` Lancelot SIX
2023-01-27 23:50             ` Tom Tromey
2023-01-30 17:43               ` Lancelot SIX
2023-01-30 18:46                 ` Mark Wielaard
2023-01-30 21:08                   ` Tom Tromey
2023-02-04 11:36                     ` Mark Wielaard
2023-01-31 10:00                   ` Lancelot SIX
2022-12-13  2:48 ` Frank Ch. Eigler
2023-02-16  8:53 anix

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y+2tppd4SjKGksWY@adacore.com \
    --to=brobecker@adacore.com \
    --cc=aburgess@redhat.com \
    --cc=gdb@sourceware.org \
    --cc=luis.machado@arm.com \
    --cc=mark@klomp.org \
    --cc=simark@simark.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).