qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Markus Armbruster" <armbru@redhat.com>,
	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: Thu, 5 Jun 2025 12:56:04 +0100	[thread overview]
Message-ID: <aEGF1FVWyIWNVamw@redhat.com> (raw)
In-Reply-To: <CAFEAcA-QPO4jPEs9ZbS3ed0LARe4caFnNC54zi=+XsFdS0Wz7g@mail.gmail.com>

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.

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



  reply	other threads:[~2025-06-05 11:57 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é [this message]
2025-06-06  6:26       ` Markus Armbruster
2025-06-06  7:17         ` Daniel P. Berrangé
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=aEGF1FVWyIWNVamw@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 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).