Lines Matching full:stable

62     git remote add -t master stable \
63       https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
141        git remote set-branches --add stable linux-6.1.y
142        git fetch stable
261 even if you face a problem with a kernel from a 'stable/longterm' series
322     * Something regressed when updating from a stable/longterm release
324       stable/longterm version based on one (say 6.1.5)? Then consider the
331       a later one (like 6.1-rc1) or a stable/longterm release based on it
335     * Something regressed when updating within a stable/longterm series (say
384   preparing things to add branches for stable/longterm series later::
389     git remote add -t master stable \
390       https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
396 * Is one of the versions you earlier established as 'good' or 'bad' a stable or
400     git remote set-branches --add stable linux-6.1.y
401     git fetch stable
545   * Are your 'good' and 'bad' versions from the same stable or longterm series?
551       git switch --discard-changes --detach stable/linux-6.1.y
662 * Did you just built a stable or longterm kernel? And were you able to reproduce
694   stable team. See Documentation/admin-guide/reporting-issues.rst for details.
870   * Did you face a regression within a stable/longterm series (say between
874       git fetch stable
882     If you bisected a regression within a stable/longterm series that also
999   * In case you want to test a stable or longterm kernel, first add the branch
1003       git remote set-branches --add stable linux-6.2.y
1008       git fetch stable
1009       git switch --discard-changes --detach stable/linux-6.2.y
1203 except when a regression occurred when switching from a release of one stable
1208 stable series 6.0.y branched to the side. It's therefore theoretically possible
1212 stable/longterm maintainers maintain the code. It's thus pretty safe to assume
1306     git remote add -t master stable \
1307       https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
1325     git remote add -t master stable \
1326       https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
1335 Afterwards add the stable Git repository as remote and all required stable
1545   <https://debian-handbook.info/browse/stable/sect.kernel-compilation.html>`_
1595 distributor or face a regression within a stable/longterm series. But it's
1616   regression you encountered with a stable/longterm release as well, as they are
1621 * For regressions within a stable/longterm series it's furthermore crucial to
1625   * Regressions specific to a stable/longterm series are the stable team's
1629     developers and maintainers have to handle; the stable team does not care
1832 * In case you encountered the regression with a stable/longterm kernel it might
1840 Check the kernel built from the latest stable/longterm codebase
1843   *Are you facing a regression within a stable/longterm release, but failed to
1877 stable/longterm kernels of different series (e.g. 6.0.13..6.1.5): it will
1912 mainline and the latest version from an affected stable/longterm series were
2018 a stable/longterm series, but Git failed to revert the commit in mainline? Then
2019 try to revert the culprit in the affected stable/longterm series -- and if that