From: Junio C Hamano <gitster@pobox.com>
To: Christian Couder <christian.couder@gmail.com>
Cc: "brian m. carlson" <sandals@crustytoothpaste.net>,
Elijah Newren <newren@gmail.com>,
git@vger.kernel.org, Taylor Blau <me@ttaylorr.com>,
Rick Sanders <rick@sfconservancy.org>,
Git at SFC <git@sfconservancy.org>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Patrick Steinhardt <ps@pks.im>,
Christian Couder <chriscool@tuxfamily.org>
Subject: Re: [PATCH v2] SubmittingPatches: add section about AI
Date: Thu, 23 Oct 2025 10:32:07 -0700 [thread overview]
Message-ID: <xmqqfrb9v814.fsf@gitster.g> (raw)
In-Reply-To: <xmqqv7ki1xf1.fsf@gitster.g> (Junio C. Hamano's message of "Mon, 13 Oct 2025 11:14:42 -0700")
Junio C Hamano <gitster@pobox.com> writes:
> I do not have strong preference either way. Even if the wording is
> firm, it is really up to each contributor to honor the guideline and
> be honest with us. You may see autocorrection in your editor fix a
> typo for you, and more advanced tools may offer to rewrite what you
> wrote, whether it is prose or code. It is very plausible that,
> especially for simple fixes, the result may be what the contributor
> would have arrived on their own anyway, and in such a case, even the
> contributor would not even know how much came from "AI" or simple
> dictionary, or if that AI learned with things you should not have
> seen.
>
> So, I do not think it makes too big a difference in practice whether
> we adopt the QEMU with minimum rewrite, or the version you posted.
> As the one you sent is in line with what we give applicants of our
> mentoring programs, and it was read over by our SFC lawyer, I'd
> prefer to keep the version I already have in my tree. Not moving on
> either, I think, is worse than adopting either in this case.
Taking time to discuss before deciding on an important issue is one
thing, but waiting for more input to happen and not moving in either
direction is worse than picking one and move on. As I said above, I
do not quite see material difference between either one in practice.
I guess it is time to make an executive decision to merge it down to
'next'. We can still tweak the language if we want, but it is more
important to have a written policy to reject materials of unknown
origin (whether it came from generative AI or not) than not having
one while we wish to be able to pick the best policy, waiting for a
better argument to come from somewhere.
As to Elijah's concern about grandfathering, I do not think it has
much practical benefit to make such a declaration. If it turns out
that older "contributions" had added something we shouldn't have,
regardless of how it was generated (either from generative AI or a
human contributor typing while unconciously recalling what they saw
elsewhere), we may need to revert it anyway, so we will deal with it
when it becomes an issue.
next prev parent reply other threads:[~2025-10-23 17:32 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-30 20:32 [RFC/PATCH] SubmittingPatches: forbid use of genAI to generate changes Junio C Hamano
2025-06-30 21:07 ` brian m. carlson
2025-06-30 21:23 ` Collin Funk
2025-07-01 10:36 ` Christian Couder
2025-07-01 11:07 ` Christian Couder
2025-07-01 17:33 ` Junio C Hamano
2025-07-01 16:20 ` Junio C Hamano
2025-07-08 14:23 ` Christian Couder
2025-10-01 14:02 ` [PATCH v2] SubmittingPatches: add section about AI Christian Couder
2025-10-01 18:59 ` Chuck Wolber
2025-10-01 23:32 ` brian m. carlson
2025-10-02 2:30 ` Ben Knoble
2025-10-03 13:33 ` Christian Couder
2025-10-01 20:59 ` Junio C Hamano
2025-10-03 8:51 ` Christian Couder
2025-10-03 16:20 ` Junio C Hamano
2025-10-03 16:45 ` rsbecker
2025-10-08 7:22 ` Christian Couder
2025-10-01 21:37 ` brian m. carlson
2025-10-03 14:25 ` Christian Couder
2025-10-03 20:48 ` Elijah Newren
2025-10-03 22:20 ` brian m. carlson
2025-10-06 17:45 ` Junio C Hamano
2025-10-08 4:18 ` Elijah Newren
2025-10-12 15:07 ` Junio C Hamano
2025-10-08 9:28 ` Christian Couder
2025-10-13 18:14 ` Junio C Hamano
2025-10-23 17:32 ` Junio C Hamano [this message]
2025-10-08 4:18 ` Elijah Newren
2025-10-08 8:37 ` Christian Couder
2025-10-08 9:28 ` Michal Suchánek
2025-10-08 9:35 ` Christian Couder
2025-10-09 1:13 ` Collin Funk
2025-10-08 7:30 ` Christian Couder
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=xmqqfrb9v814.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=chriscool@tuxfamily.org \
--cc=christian.couder@gmail.com \
--cc=git@sfconservancy.org \
--cc=git@vger.kernel.org \
--cc=me@ttaylorr.com \
--cc=newren@gmail.com \
--cc=ps@pks.im \
--cc=rick@sfconservancy.org \
--cc=sandals@crustytoothpaste.net \
/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 NNTP newsgroup(s).