Re: [docs] how should one update "dual, six-core Xeons"?

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Mon, 2026-09-14 at 09:01 -0400, Robert P. J. Day wrote:
> On Mon, 14 Sep 2026, Antonin Godard wrote:
> > On Mon Sep 14, 2026 at 11:46 AM CEST, Robert P. J. Day wrote:
> > > On Mon, 14 Sep 2026, Richard Purdie wrote:
> > > > On Mon, 2026-09-14 at 10:36 +0200, Antonin Godard via
> > > > lists.yoctoproject.org wrote:
> > > > > On Fri Sep 11, 2026 at 8:08 PM CEST, Robert P. J. Day wrote:
> > > > > > 
> > > > > > here:
> > > > > > 
> > > > > > https://docs.yoctoproject.org/dev/dev-manual/start.html
> > > > > > 
> > > > > > it's amusing to read, "These systems, in general, should be
> > > > > > high
> > > > > > performance (e.g. dual, six-core Xeons with 24 Gbytes of
> > > > > > RAM and
> > > > > > plenty of disk space)."
> > > > > > 
> > > > > > would someone like to suggest a more modern configuration,
> > > > > > and i'll
> > > > > > submit a patch.
> > > > > 
> > > > > We could simply say: "&MIN_RAM; Gbytes of RAM, at least
> > > > > &MIN_DISK_SPACE; disk
> > > > > space".
> > > > > 
> > > > > Those are replaced by our poky.yaml.in replacements when
> > > > > building.
> > > > > 
> > > > > Not sure we need to mention a processor model here, as it
> > > > > would become obsolete
> > > > > in the future.
> > > > 
> > > > I think the key is to mention multi cored system, "ideally with
> > > > at least 16 cores"?
> > > 
> > >   i can submit a v2 with that info, but would that be hard-coded
> > > since
> > > there is no variable in poky.yaml.in that relates to that.
> > 
> > Right, I think we could hold this value next to MIN_RAM and
> > MIN_DISK_SPACE, so
> > we keep all of them in sync.
> > 
> > I think we should add MIN_CPU_CORES in a patch, then use this value
> > next to
> > where MIN_DISK_SPACE and MIN_RAM are used in the docs.
> 
>   we can do this in two steps, and someone else higher up the food
> chain can peruse poky.yaml.in and decide if there are any other
> variables that can be added that would be useful in the docs, after
> which i'll submit a patch to take care of my little issue and others
> can think where else those new variables can be used.

Can you not just send some patches helping to fix the various issues?
Do we need "someone else higher up in the food chain"?

What you're doing here is creating work for others :/

Cheers,

Richard