Re: [docs] [PATCH v2 2/9] dev-manual-common-tasks: Fix refs to testing branches

["Nicolas Dechesne" <nicolas.dechesne@linaro.org>]

On Mon, Nov 23, 2020 at 4:40 PM Paul Barker <pbarker@konsulko.com> wrote:
>
> On Wed, 18 Nov 2020 at 11:23, Nicolas Dechesne
> <nicolas.dechesne@linaro.org> wrote:
> >
> > On Wed, Nov 18, 2020 at 11:07 AM Paul Barker <pbarker@konsulko.com> wrote:
> > >
> > > After discussions on IRC with Ross we concluded that the `ross/mut`
> > > branch shouldn't really be listed in the docs as it's more of a personal
> > > test branch. Instead we should list the -next branches for
> > > openembedded-core and poky.
> > >
> > > Signed-off-by: Paul Barker <pbarker@konsulko.com>
> > > ---
> > >  .../dev-manual/dev-manual-common-tasks.rst    | 33 ++++++++++++-------
> > >  1 file changed, 21 insertions(+), 12 deletions(-)
> > >
> > > diff --git a/documentation/dev-manual/dev-manual-common-tasks.rst b/documentation/dev-manual/dev-manual-common-tasks.rst
> > > index 27aacde60..6f526c203 100644
> > > --- a/documentation/dev-manual/dev-manual-common-tasks.rst
> > > +++ b/documentation/dev-manual/dev-manual-common-tasks.rst
> > > @@ -10665,18 +10665,27 @@ to a contribution repository that is upstream. See the ":ref:`gs-git-workflows-a
> > >  section in the Yocto Project Overview and Concepts Manual for additional
> > >  concepts on working in the Yocto Project development environment.
> > >
> > > -Two commonly used testing repositories exist for OpenEmbedded-Core:
> > > -
> > > --  *"ross/mut" branch:* The "mut" (master-under-test) tree exists in the
> > > -   ``poky-contrib`` repository in the
> > > -   :yocto_git:`Yocto Project source repositories <>`.
> > > -
> > > --  *"master-next" branch:* This branch is part of the main "poky"
> > > -   repository in the Yocto Project source repositories.
> > > -
> > > -Maintainers use these branches to test submissions prior to merging
> > > -patches. Thus, you can get an idea of the status of a patch based on
> > > -whether the patch has been merged into one of these branches.
> > > +Maintainers commonly use ``-next`` branches to test submissions prior to
> > > +merging patches. Thus, you can get an idea of the status of a patch based on
> > > +whether the patch has been merged into one of these branches. The commonly
> > > +used testing branches for OpenEmbedded-Core are as follows:
> > > +
> > > +-  *openembedded-core "master-next" branch:* This branch is part of the
> > > +   :oe_git:`openembedded-core </openembedded-core/>` repository contains
> > > +   proposed changes to the core metadata.
> > > +
> > > +-  *poky "master-next" branch:* This branch is part of the
> > > +   :yocto_git:`poky </cgit/cgit.cgi/poky/>` repository and combines proposed
> > > +   changes to bitbake, the core metadata and the poky distro.
> > > +
> > > +Similarly, stable branches maintained by the project may have corresponding
> > > +``-next`` branches which collect proposed changes. For example,
> > > +``dunfell-next`` and ``gatesgarth-next`` branches in both the
> > > +"openembdedded-core" and "poky" repositories.
> >
> > Perhaps using DISTRO_NAME_NO_CAP and DISTRO_NAME_NO_CAP_MINUS_ONE
> > here, so that the documentation stays 'current' over the years?
> > I think it's a good idea to keep 'dunfell-next' though (since it's
> > LTS), so perhaps we can add DISTRO_NAME_NO_CAP_LTS variable which
> > points to latest LTS, and use it and DISTRO_NAME_NO_CAP here.
>
> I'm making the changes today and I realised this may lead to confusion
> for the next LTS release. How about we define
> DISTRO_NAME_NO_CAP_PREV_LTS and then we can say that it will never be
> equal to DISTRO_NAME_NO_CAP?

I think we need:

DISTRO_NAME_NO_CAP : the current release
DISTRO_NAME_NO_CAP_MINUS_ONE : the previous release
DISTRO_NAME_NO_CAP_LTS : the current LTS release (and yes, it might be
DISTRO_NAME_NO_CAP right after an LTS)

Then we should be able to address pretty much anything we need, no?
Perhaps we can add DISTRO_NAME_NO_CAP_LTS_PREV eventually..


>
> --
> Paul Barker
> Konsulko Group