From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
qemu-devel@nongnu.org, "Thomas Huth" <thuth@redhat.com>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Michael S . Tsirkin" <mst@redhat.com>,
"Gerd Hoffmann" <kraxel@redhat.com>,
"Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Kevin Wolf" <kwolf@redhat.com>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"Alexander Graf" <agraf@csgraf.de>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Richard Henderson" <richard.henderson@linaro.org>
Subject: Re: [PATCH v4 2/3] docs: define policy limiting the inclusion of generated files
Date: Fri, 6 Jun 2025 08:17:37 +0100 [thread overview]
Message-ID: <aEKWEWqommsJHnDd@redhat.com> (raw)
In-Reply-To: <87qzzx9yhu.fsf@pond.sub.org>
On Fri, Jun 06, 2025 at 08:26:37AM +0200, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
>
> > On Thu, Jun 05, 2025 at 12:38:09PM +0100, Peter Maydell wrote:
> >> On Thu, 5 Jun 2025 at 11:52, Markus Armbruster <armbru@redhat.com> wrote:
> >> > +At times contributors may use or create scripts/tools to generate an initial
> >> > +boilerplate code template which is then filled in to produce the final patch.
> >> > +The output of such a tool would still be considered the "preferred format",
> >> > +since it is intended to be a foundation for further human authored changes.
> >> > +Such tools are acceptable to use, provided they follow a deterministic process
> >> > +and there is clearly defined copyright and licensing for their output.
> >>
> >> For the case where there's a one-off generation step and then the
> >> intent is purely human-authored changes from there onwards, why
> >> do we care whether the tool followed a deterministic process or
> >> not? As long as the copyright/licensing situation is clear and
> >> the submitter has checked tha the generation is what they want,
> >> what does determinism get us?
> >
> > The copyright/licensing is important, but it was trying to say
> > more than that to limit the scenarios in which generated code
> > would be contributed. I think determinism in the tool's operation
> > is valuable, but probably not the key point to get across here.
> >
> > We don't want a free for all in hand editting and then contributnig
> > any auto-generated content. We only want generated content included
> > where it was explicitly intended that it serve as a "template" for
> > human refinement.
> >
> > Determinisism in the sense that if a 2nd person used the same
> > tool to auto-generate the base template for editting, they would
> > be starting from the same place as the original contributior.
> >
> >> As a trivial example, this rules out a hacky one-off python
> >> script that produces output by iterating through a hashtable
> >> if you forgot to add a "sort" to that ordering to make it
> >> deterministic.
> >
> > NB it is trying to say that the way the tool operates is determinstic,
> > not that its output is neccessarily stable wrt things like sorting.
> > ie you can rationalize about what the tool is going to emit, but.
>
> I think the paragraph's purpose is to clarify "preferred format" is what
> developers want to work with going forward even when the initial
> contribution started with generated contents.
>
> I think the "deterministic process" clause distracts from this.
> Moreover, it feels largely redundant with the next patch's "Use of AI
> content generators". Scratch the clause?
>
> Such tools are acceptable to use, provided and there is clearly defined
> copyright and licensing for their output.
Fine for me.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2025-06-06 7:18 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-05 10:52 [PATCH v4 0/3] docs: define policy forbidding use of "AI" / LLM code generators Markus Armbruster
2025-06-05 10:52 ` [PATCH v4 1/3] docs: introduce dedicated page about code provenance / sign-off Markus Armbruster
2025-06-05 13:53 ` Alex Bennée
2025-06-05 10:52 ` [PATCH v4 2/3] docs: define policy limiting the inclusion of generated files Markus Armbruster
2025-06-05 11:38 ` Peter Maydell
2025-06-05 11:56 ` Daniel P. Berrangé
2025-06-06 6:26 ` Markus Armbruster
2025-06-06 7:17 ` Daniel P. Berrangé [this message]
2025-06-05 10:52 ` [PATCH v4 3/3] docs: define policy forbidding use of AI code generators Markus Armbruster
2025-06-05 13:58 ` Alex Bennée
2025-06-05 11:52 ` [PATCH v4 0/3] docs: define policy forbidding use of "AI" / LLM " Stefan Hajnoczi
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=aEKWEWqommsJHnDd@redhat.com \
--to=berrange@redhat.com \
--cc=agraf@csgraf.de \
--cc=alex.bennee@linaro.org \
--cc=armbru@redhat.com \
--cc=kraxel@redhat.com \
--cc=kwolf@redhat.com \
--cc=mark.cave-ayland@ilande.co.uk \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=stefanha@redhat.com \
--cc=thuth@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.