Re: [docs] [PATCH v2 22/56] overview-manual/development-environment.rst: remove obsolete poky repo references

[Quentin Schulz <quentin.schulz@cherry.de>]

Hi Antonin,

On 1/27/26 9:19 AM, Antonin Godard via lists.yoctoproject.org wrote:
> Remove references to the Poky repository, replace by OpenEmbedded-Core.
> Replace the poky examples for the Git section by yocto-docs.
> 
> Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
> ---
>   .../overview-manual/development-environment.rst    | 83 +++++++++++-----------
>   1 file changed, 41 insertions(+), 42 deletions(-)
> 
> diff --git a/documentation/overview-manual/development-environment.rst b/documentation/overview-manual/development-environment.rst
> index ab9bd084c..0402e3456 100644
> --- a/documentation/overview-manual/development-environment.rst
> +++ b/documentation/overview-manual/development-environment.rst
> @@ -148,44 +148,42 @@ code browser is organized into categories by function such as IDE
>   Plugins, Matchbox, Poky, Yocto Linux Kernel, and so forth. From the
>   interface, you can click on any particular item in the "Name" column and
>   see the URL at the bottom of the page that you need to clone a Git
> -repository for that particular item. Having a local Git repository of
> -the :term:`Source Directory`, which
> -is usually named "poky", allows you to make changes, contribute to the
> +repository for that particular item. Having a local Git clone of
> +these repositories allows you to make changes, contribute to the
>   history, and ultimately enhance the Yocto Project's tools, Board Support
>   Packages, and so forth.
>   
>   For any supported release of Yocto Project, you can also go to the
> -:yocto_home:`Yocto Project Website <>` and select the "DOWNLOADS"
> -item from the "SOFTWARE" menu and get a released tarball of the ``poky``
> -repository, any supported BSP tarball, or Yocto Project tools. Unpacking
> +:yocto_home:`Yocto Project Website <>` and select the "RELEASES"
> +item from the "DEVELOPMENT" menu and get a released tarball of the

Why making it harder to maintain by telling the user where to click 
instead of just providing a direct link which we can check with 
linkcheck if we want to?

s/RELEASES/Releases/

s/DEVELOPMENT/Development/

[...]

> --  :yocto_home:`DOWNLOADS page </software-overview/downloads/>`:
> -   The :yocto_home:`Yocto Project website <>` includes a "DOWNLOADS" page accessible
> +-  :yocto_home:`RELEASES page </development/releases/>`:
> +   The :yocto_home:`Yocto Project website <>` includes a "RELEASES" page accessible
>      through the "SOFTWARE" menu that allows you to download any Yocto

through the "Development" menu.

Also, they all are capitalized but not uppercase, i.e. Releases and not 
RELEASES.

>      Project release, tool, and Board Support Package (BSP) in tarball
>      form. The hyperlinks point to the tarballs under
> @@ -230,11 +228,11 @@ and so forth.
>      ":doc:`/contributor-guide/identify-component`"
>      section of the Yocto Project and OpenEmbedded Contributor Guide.
>   
> -The Yocto Project ``poky`` Git repository also has an upstream
> -contribution Git repository named ``poky-contrib``. You can see all the
> +The Yocto Project Git repositories may also have upstream
> +contribution Git repositories suffixed with ``-contrib``. You can see all the
>   branches in this repository using the web interface of the

Reported in v1:

You mention there can be multiple repositories but here you say "this
repository" which is confusing. Maybe use one of the contrib git repos
as example.

[...]

> @@ -449,19 +446,19 @@ The most common use is to checkout a working branch that matches a
>   specific Yocto Project release. Here is an example::
>   
>      $ cd ~
> -   $ git clone git://git.yoctoproject.org/poky
> -   $ cd poky
> +   $ git clone git://git.yoctoproject.org/yocto-docs
> +   $ cd yocto-docs
>      $ git fetch --tags
> -   $ git checkout tags/rocko-18.0.0 -b my_rocko-18.0.0
> +   $ git checkout tags/&DISTRO_NAME_NO_CAP;-&DISTRO; -b my_&DISTRO_NAME_NO_CAP;-&DISTRO;
>   
>   In this example, the name
>   of the top-level directory of your local Yocto Project repository is
> -``poky``. After moving to the ``poky`` directory, the ``git fetch``
> +``yocto-docs``. After moving to the ``yocto-docs`` directory, the ``git fetch``
>   command makes all the upstream tags available locally in your
>   repository. Finally, the ``git checkout`` command creates and checks out
> -a branch named "my-rocko-18.0.0" that is based on the upstream branch
> +a branch named "my_&DISTRO_NAME_NO_CAP;-&DISTRO;" that is based on the upstream branch
>   whose "HEAD" matches the commit in the repository associated with the
> -"rocko-18.0.0" tag. The files in your repository now exactly match that
> +"&DISTRO_NAME_NO_CAP;-&DISTRO;" tag. The files in your repository now exactly match that

Technicality but I believe this is incorrect in git. The only thing that 
matters is you check out a tag. The tag may not necessarily be on a 
branch (it is for us, but it doesn't *have* to be). Also, HEAD of 
whinlatter may not be the latest release tag so that is actually incorrect.

I guess we could make this a bit more palatable (and proper) by 
rewording to:

that is based on the upstream tag in the repository.

Maybe? Separate patch/series though, not a blocker here.

Cheers,
Quentin