All of lore.kernel.org
 help / color / mirror / Atom feed
From: Quentin Schulz <quentin.schulz@cherry.de>
To: peter.marko@siemens.com,
	"JPEWhacker@gmail.com" <JPEWhacker@gmail.com>,
	"openembedded-core@lists.openembedded.org"
	<openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core][PATCH] AGENTS.md: Add file
Date: Tue, 11 Aug 2026 11:12:46 +0200	[thread overview]
Message-ID: <03cf8e4e-72d2-4d55-b23e-209f50ced994@cherry.de> (raw)
In-Reply-To: <AS8PR10MB5073A8A1830344344A974B7EFDDD2@AS8PR10MB5073.EURPRD10.PROD.OUTLOOK.COM>



On 8/11/26 10:22 AM, Peter Marko via lists.openembedded.org wrote:
> 
> 
>> -----Original Message-----
>> From: openembedded-core@lists.openembedded.org <openembedded-
>> core@lists.openembedded.org> On Behalf Of Joshua Watt via
>> lists.openembedded.org
>> Sent: Monday, August 10, 2026 6:12 PM
>> To: openembedded-core@lists.openembedded.org
>> Cc: Joshua Watt <JPEWhacker@gmail.com>
>> Subject: [OE-core][PATCH] AGENTS.md: Add file
>>
>> Adds an AGENTS.md file to direct agents about better commit practices.
>> This is specifically *not* attempting to improve or direct agents about
>> the code that they generate. It has been noted that when AI is used to
>> write code and commit code, the commit messages that it generates can be
>> long and draw out (e.g. a "wall of text") which affects maintainer
>> ability to review the patches. Therefore, this AGENTS.md text file is
>> only focused on instructing the agents to produce commits that are more
>> suitable for our review process.
>>
>> This file is intended to help agents comply with the existing project
>> document (and specifically, the AI Policy[1]), and does not constitute a
>> new policy. Any subsequent changes to this file should derive and comply
>> with the project documentation and policies.
>>
>> It what can only be described as the most bizarre interaction with a
>> computer I've ever experienced, the best way to get an AGENTS.md file
>> that AI agents actually respect as intended is to instruct one to write
>> it for you (as opposed to writing one by hand). Future edits to this
>> file will likely be most effective if written by an Agent.
>>
>> [1]: https://docs.yoctoproject.org/contributor-guide/submit-
>> changes.html#acceptance-of-ai-generated-code
>> AI-Generated: Uses Claude Sonnet 5
>>
>> Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
>> ---
>>   AGENTS.md | 55
>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>   1 file changed, 55 insertions(+)
>>   create mode 100644 AGENTS.md
>>
>> diff --git a/AGENTS.md b/AGENTS.md
>> new file mode 100644
>> index 0000000000..ce4d6d9e6e
>> --- /dev/null
>> +++ b/AGENTS.md
>> @@ -0,0 +1,55 @@
>> +# AGENTS.md — OpenEmbedded-Core & BitBake
>> +
>> +Guidance for AI agents working in the `openembedded-core` repository.
>> +
>> +## Making changes
>> +
>> +- No web PR workflow. The project use **patches on mailing lists**
>> +  (openembedded-core@lists.openembedded.org) tracked via patchwork. Don't
>> +  assume GitHub PR conventions apply.
>> +- One Git commit per logical change (e.g., one commit per recipe
>> added/upgraded).
>> +- Commit message format:
>> +  - Summary line prefixed with the recipe name or short file path,
>> +    e.g. `openssl: upgrade to 3.2.1` or `classes/rootfs-postcommands: fix typo`.
> 
> Current standard for upgrade commit message is "openssl: upgrade 3.2.0 -> 3.2.1"
> 
>> +    Check `git log --oneline <path>` for the prefix convention already in use.
>> +  - Body explains what/why/how, and how it was tested.
>> +  - Prefer explaining *why* a change was made over restating what's
>> +    already visible in the diff, unless the diff is long/hard to follow
>> +    or the reason for the change isn't known — in those cases, summarize
>> +    what changed instead.
>> +  - Be succinct: use as few sentences and lines as possible while still
>> +    covering what/why/how. Cut restatements, filler, and any detail a
>> +    reviewer wouldn't need (e.g. exact test-run counts, step-by-step
>> +    narration). One short paragraph is usually enough; only add a second
>> +    if a distinct point (e.g. testing) needs it.
>> +  - The most relevant information about the change should be presented first.
>> +  - Reference bugs as `Fixes [YOCTO #1234]` when applicable.
>> +  - Use `Reported-by`, `Suggested-by`, `Tested-by`, `Reviewed-by`, `Cc` tags
>> +    where relevant.
> 
> Where should the agent get yocto bugzilla ID or the personal tags from?
> This may lead to hallucinations.
> Maybe we can suggest to ask/remind user about those?
> 
>> +
>> +### AI-generated code
>> +
>> +- **Mandatory**: any AI-generated code/commit must add an `AI-Generated:`
>> +  tag line in the commit message, placed *before* `Signed-off-by` (if present),
>> +  naming the tool used, e.g.:
>> +
>> +  ```
>> +  component: Add the ability to ...
>> +
>> +  AI-Generated: Uses GitHub Copilot
>> +  ```
>> +
>> +- Also add a code comment or other in-patch indication that the code is
>> +  AI-generated (recommended, not just the commit tag).
>> +- **Mandatory** Do not automatically add a `Signed-off-by`. This tag must
>> +  always be written by the human contributor, never by the AI tool — the
>> +  DCO/Developer's Statement of Origin still applies in full.
>> +- Contributor is responsible for confirming the AI tool's terms don't
>> +  conflict with the project's open source license/IP policy, and that
>> +  any third-party copyrighted material in the AI output is properly
>> +  licensed before contributing it. See the Linux Foundation generative AI
>> +  guidance: https://www.linuxfoundation.org/legal/generative-ai.
>> +- `Co-authored-by` should be omitted in favor of the `AI-generated` tag.
> 
> Do you have references about AI-generated git tags?
> I think that the AssistedBy is the current state-of-the-art way of annotating this...
> 

https://docs.yoctoproject.org/contributor-guide/submit-changes.html#acceptance-of-ai-generated-code


  reply	other threads:[~2026-08-11  9:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-10 16:11 [OE-core][PATCH] AGENTS.md: Add file Joshua Watt
2026-08-11  8:22 ` Marko, Peter
2026-08-11  9:12   ` Quentin Schulz [this message]
2026-08-11 15:04   ` Joshua Watt
2026-08-17 20:04 ` [OE-core][PATCH v2] " Joshua Watt

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=03cf8e4e-72d2-4d55-b23e-209f50ced994@cherry.de \
    --to=quentin.schulz@cherry.de \
    --cc=JPEWhacker@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=peter.marko@siemens.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.