Re: [bitbake-devel] [PATCH] bitbake-setup: preserve build config when init script is missing

It has become fairly clear that we have incompatible views on what
constitutes acceptable use of AI. For that reason, thank you for the
discussion, but I’d prefer to move on.

On Wed, 19 Aug 2026 14:49:38 +0200, Alexander Kanavin
<[email protected]> wrote:
> On Wed, 19 Aug 2026 at 12:51, Giancarlo Cicellyn Comneno
> <[email protected]> wrote:
> > I understand that you personally expect review conversations to be
> > written without AI assistance. That expectation was not clear to me
> > before, but now it is. I accept that this is how you prefer to
> > interact with contributors, even though for me using AI assistance is
> > part of how I work and learn, and it saves time that I can spend on
> > the technical work itself and on the other projects I handle in
> > parallel.
>
> There's a growing community consensus about this: reviewers want to
> talk with humans, and giving them AI generated replies is likely to
> antagonize and frustrate them. It gets worse when people keep doing it
> despite being asked to stop, and then get defensive about it.
>
> E.g. Rust has already spelled it out clearly:
> https://blog.rust-lang.org/inside-rust/2026/08/05/rust-langrust-is-adopting-an-llm-policy/#mechanically-copy-pasting-llm-output-is-a-waste-of-time
>
> They say:
> ===
> We will often get people who respond to review comments by
> copy-pasting them into their LLM, then copy-pasting its response back
> onto GitHub. Bluntly: this is a waste of everyone's time. If we wanted
> an LLM's opinion, we could have asked it ourselves. We want to hear
> your thoughts, not a machine's.
>
> Moreover, this is a breach of trust between the reviewer and the
> author. Our assumption when we review is that we're talking to a real
> person who wants to do their best work. Pasting LLM text creates
> suspicion: does the author actually care? Is there a person here at
> all?
> ===
>
> I have also written about this here, which touches on the reasons I
> want interaction with humans:
> https://www.linkedin.com/feed/update/urn:li:activity:7490778888923541504/
>
> Do take your own reputation much more seriously than any possible time
> savings (which often end up negated through actual human review and
> having to manually establish and then rework AI mistakes or incorrect
> assumptions).
>
> Yocto is going to tweak the policy to more clearly say what is okay
> and what isn't, the exact wording is under consideration:
> https://lists.openembedded.org/g/openembedded-core/message/243686
>
> > What I can tell you accurately is that the goal was to learn on the
> > job by auditing `bitbake-setup`, looking for problematic or fragile
> > failure paths, and trying to validate anything found with tests before
> > proposing a fix. This patch came out of that process. It did not come
> > from a real OE-Core incident or from a user bug report, and I already
> > made that clear in my previous reply.
>
> The patches would've been better received if this was done first:
>
> - research whether the scenarios they fix are realistic *before*
> submission. You are free to use AI any way you want in that activity.
>
> - if that research was inconclusive, or you lack experience to make
> that judgement, then mark the patches as RFC, and add your own
> commentary to the commit messages: specifically that you have asked AI
> to find problems, but you are not sure if the discovered problems are
> real, and seek community feedback.
>
> At the very least, this last bit should've been written in a response
> to my question, by *you*.
>
> Keep this in mind: you can't assume reviewers are compensated for
> doing reviews, and all too often in open source they're not, or their
> time is stretched extremely thin. For example, I'm not getting paid to
> have this conversation. So any needed research needs to happen up
> front, so that you don't end up asking me, or anyone, to explain
> things for you, or prove to you that the patches aren't necessary.
>
> > Is your technical objection that the source transition exercised by
> > the test is outside the supported contract of `bitbake-setup`?
> >
> > Or is the concern instead that the transition is technically possible
> > but too theoretical / unrealistic to justify an upstream patch?
> >
> > I am asking because those are two different conclusions, and I would
> > genuinely like to learn which one applies here.
>
> The questions to ask, as part of that upfront research I mentioned
> above, is neither of these. It's "What are these files used for? How
> likely are they to be removed?"
>
> scripts/oe-setup-build is used to set up a bitbake build directory
> from a configuration template in a layer. Oe-init-build-env is used to
> set bitbake-specific variables in a unix environment so that bitbake
> can find metadata and the bitbake build directory set up by
> oe-setup-build, and then run actual yocto builds.
>
> Both files are a core part of yocto workflows, they're standard,
> documented, and especially oe-init-build-env is used by almost
> everyone. So they will stay in oe-core repository until the end of
> time; it's completely unrealistic to remove them from that repo.
>
> > In any case, thank you for the time you have spent reviewing this. I
> > am here primarily to learn by doing useful work, and I have no
> > interest in defending a patch whose premise does not hold.
>
> If you'd like to help, it's best to first establish what would be
> helpful. Let me assure you: AI assisted bug hunting is not where help
> would be most appreciated. Again, it's best to ask the community first
> what you could do, given your level of experience and particular
> interests and goals. Or read the weekly status emails such as one I
> linked above, where the most pressing issues are highlighted.
>
> Alex