This is a RFC and a bit rough for now. I only set down to create the
first of the three patches. But while doing so I noticed a few things
that seemed odd for me with my background on writing and editing texts.
So I just quickly performed a few additional changes to fix those to see
if the stable team would appreciate them, as this document is clearly
their domain.
If those changes or even the initial patch are not welcomed, I'll simply
drop them. I'd totally understand this, as texts like these are delicate
and it's easy to accidentlly change the intent or the meaning while
adjusting things in good faith.
At the same time I might be willing to do a few more changes, if people
like the direction this takes and want a bit more fine tuning.
CC: Greg KH <[email protected]>
CC: Sasha Levin <[email protected]>
CC: Jonathan Corbet <[email protected]>
Thorsten Leemhuis (3):
docs: stable-kernel-rules: mention other usages for stable tag
comments
docs: stable-kernel-rules: make rule section more straight forward
docs: stable-kernel-rules: improve structure to optimize reading flow
Documentation/process/stable-kernel-rules.rst | 189 ++++++++++--------
1 file changed, 105 insertions(+), 84 deletions(-)
base-commit: 016571b6d52deb473676fb4d24baf8ed3667ae21
--
2.40.1
Document how to delay backporting or send a note to the stable team
using shell-style inline comments attached to stable tags.
CC: Greg KH <[email protected]>
CC: Sasha Levin <[email protected]>
CC: Jonathan Corbet <[email protected]>
Signed-off-by: Thorsten Leemhuis <[email protected]>
---
Documentation/process/stable-kernel-rules.rst | 22 ++++++++++++++++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst
index 51df1197d5ab..6e4026dd6882 100644
--- a/Documentation/process/stable-kernel-rules.rst
+++ b/Documentation/process/stable-kernel-rules.rst
@@ -55,9 +55,10 @@ To have the patch automatically included in the stable tree, add the tag
Cc: [email protected]
-in the sign-off area. Once the patch is merged it will be applied to
-the stable tree without anything else needing to be done by the author
-or subsystem maintainer.
+in the sign-off area; to accompany a note to the stable team, use a shell-style
+inline comment (see below for details). Once the patch is merged it will be
+applied to the stable tree without anything else needing to be done by the
+author or subsystem maintainer.
.. _option_2:
@@ -139,6 +140,21 @@ The tag has the meaning of:
For each "-stable" tree starting with the specified version.
+To delay pick up of patches submitted via :ref:`option_1`, use the following
+format:
+
+.. code-block:: none
+
+ Cc: <[email protected]> # after 4 weeks in mainline
+
+For any other requests related to patches submitted via :ref:`option_1`, just
+add a note to the stable tag. This for example can be used to point out known
+problems:
+
+.. code-block:: none
+
+ Cc: <[email protected]> # see patch description, needs adjustments for >= 6.3
+
Following the submission:
- The sender will receive an ACK when the patch has been accepted into the
--
2.40.1
On Mon, Jul 10, 2023 at 07:10:11PM +0200, Thorsten Leemhuis wrote:
> Document how to delay backporting or send a note to the stable team
> using shell-style inline comments attached to stable tags.
>
> CC: Greg KH <[email protected]>
> CC: Sasha Levin <[email protected]>
> CC: Jonathan Corbet <[email protected]>
> Signed-off-by: Thorsten Leemhuis <[email protected]>
> ---
> Documentation/process/stable-kernel-rules.rst | 22 ++++++++++++++++---
> 1 file changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst
> index 51df1197d5ab..6e4026dd6882 100644
> --- a/Documentation/process/stable-kernel-rules.rst
> +++ b/Documentation/process/stable-kernel-rules.rst
> @@ -55,9 +55,10 @@ To have the patch automatically included in the stable tree, add the tag
>
> Cc: [email protected]
>
> -in the sign-off area. Once the patch is merged it will be applied to
> -the stable tree without anything else needing to be done by the author
> -or subsystem maintainer.
> +in the sign-off area; to accompany a note to the stable team, use a shell-style
Is that how a ';' is really used? I never can remember, so it's an
honest question here :)
> +inline comment (see below for details). Once the patch is merged it will be
> +applied to the stable tree without anything else needing to be done by the
> +author or subsystem maintainer.
>
> .. _option_2:
>
> @@ -139,6 +140,21 @@ The tag has the meaning of:
>
> For each "-stable" tree starting with the specified version.
>
> +To delay pick up of patches submitted via :ref:`option_1`, use the following
> +format:
> +
> +.. code-block:: none
> +
> + Cc: <[email protected]> # after 4 weeks in mainline
> +
> +For any other requests related to patches submitted via :ref:`option_1`, just
> +add a note to the stable tag. This for example can be used to point out known
> +problems:
> +
> +.. code-block:: none
> +
> + Cc: <[email protected]> # see patch description, needs adjustments for >= 6.3
> +
This looks great to me, so I'll be glad to take it.
thanks,
greg k-h
On Mon, Jul 10, 2023 at 07:10:10PM +0200, Thorsten Leemhuis wrote:
> This is a RFC and a bit rough for now. I only set down to create the
> first of the three patches. But while doing so I noticed a few things
> that seemed odd for me with my background on writing and editing texts.
> So I just quickly performed a few additional changes to fix those to see
> if the stable team would appreciate them, as this document is clearly
> their domain.
>
> If those changes or even the initial patch are not welcomed, I'll simply
> drop them. I'd totally understand this, as texts like these are delicate
> and it's easy to accidentlly change the intent or the meaning while
> adjusting things in good faith.
>
> At the same time I might be willing to do a few more changes, if people
> like the direction this takes and want a bit more fine tuning.
I do like it, many thanks for taking the time to do this work, it's much
appreciated.
If you resend the first 2 as a non-RFC patch, I'll be glad to queue up,
the last one needs some more work as mentioned.
thanks,
greg k-h
On 10.07.23 21:43, Greg KH wrote:
> On Mon, Jul 10, 2023 at 07:10:11PM +0200, Thorsten Leemhuis wrote:
>> Document how to delay backporting or send a note to the stable team
>> using shell-style inline comments attached to stable tags.
>>
>> CC: Greg KH <[email protected]>
>> CC: Sasha Levin <[email protected]>
>> CC: Jonathan Corbet <[email protected]>
>> Signed-off-by: Thorsten Leemhuis <[email protected]>
>> ---
>> Documentation/process/stable-kernel-rules.rst | 22 ++++++++++++++++---
>> 1 file changed, 19 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst
>> index 51df1197d5ab..6e4026dd6882 100644
>> --- a/Documentation/process/stable-kernel-rules.rst
>> +++ b/Documentation/process/stable-kernel-rules.rst
>> @@ -55,9 +55,10 @@ To have the patch automatically included in the stable tree, add the tag
>>
>> Cc: [email protected]
>>
>> -in the sign-off area. Once the patch is merged it will be applied to
>> -the stable tree without anything else needing to be done by the author
>> -or subsystem maintainer.
>> +in the sign-off area; to accompany a note to the stable team, use a shell-style
>
> Is that how a ';' is really used? I never can remember, so it's an
> honest question here :)
Ha, better ask a native speaker or your favorite internet search engine
for advice and not someone from Germany that in school was always bad at
both German and English. ;)
But to answer the question: I think it is used this way in English "to
connect related, but independent clauses". But the relation is not that
strong or important here; I also tend use semicolons a bit too much, so
I'll just drop it for v2.
> [...]
> This looks great to me, so I'll be glad to take it.
thx!
Ciao, Thorsten
On 11.07.23 12:15, Jani Nikula wrote:
> On Mon, 10 Jul 2023, Thorsten Leemhuis <[email protected]> wrote:
> [...]
>> +To delay pick up of patches submitted via :ref:`option_1`, use the following
>> +format:
>> +
>> +.. code-block:: none
>> +
>> + Cc: <[email protected]> # after 4 weeks in mainline
>> +
>> +For any other requests related to patches submitted via :ref:`option_1`, just
>> +add a note to the stable tag. This for example can be used to point out known
>> +problems:
>> +
>> +.. code-block:: none
>> +
>> + Cc: <[email protected]> # see patch description, needs adjustments for >= 6.3
>> +
>
> To me, this seems like promoting *any* free text after the #, making it
> harder to parse in scripts.
>
> Of course, I'm only ever producing this, and never consuming, so if the
> manual reading is fine for the stable developers, who am I to argue.
I had similar concerns, to which Greg replied: ```my "script" is me
reviewing each patch :)```
FWIW, that was here:
https://lore.kernel.org/all/2023061936-eatable-grumbling-f3c1@gregkh/
Ciao, Thorsten
On Mon, 10 Jul 2023, Thorsten Leemhuis <[email protected]> wrote:
> Document how to delay backporting or send a note to the stable team
> using shell-style inline comments attached to stable tags.
>
> CC: Greg KH <[email protected]>
> CC: Sasha Levin <[email protected]>
> CC: Jonathan Corbet <[email protected]>
> Signed-off-by: Thorsten Leemhuis <[email protected]>
> ---
> Documentation/process/stable-kernel-rules.rst | 22 ++++++++++++++++---
> 1 file changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst
> index 51df1197d5ab..6e4026dd6882 100644
> --- a/Documentation/process/stable-kernel-rules.rst
> +++ b/Documentation/process/stable-kernel-rules.rst
> @@ -55,9 +55,10 @@ To have the patch automatically included in the stable tree, add the tag
>
> Cc: [email protected]
>
> -in the sign-off area. Once the patch is merged it will be applied to
> -the stable tree without anything else needing to be done by the author
> -or subsystem maintainer.
> +in the sign-off area; to accompany a note to the stable team, use a shell-style
> +inline comment (see below for details). Once the patch is merged it will be
> +applied to the stable tree without anything else needing to be done by the
> +author or subsystem maintainer.
>
> .. _option_2:
>
> @@ -139,6 +140,21 @@ The tag has the meaning of:
>
> For each "-stable" tree starting with the specified version.
>
> +To delay pick up of patches submitted via :ref:`option_1`, use the following
> +format:
> +
> +.. code-block:: none
> +
> + Cc: <[email protected]> # after 4 weeks in mainline
> +
> +For any other requests related to patches submitted via :ref:`option_1`, just
> +add a note to the stable tag. This for example can be used to point out known
> +problems:
> +
> +.. code-block:: none
> +
> + Cc: <[email protected]> # see patch description, needs adjustments for >= 6.3
> +
To me, this seems like promoting *any* free text after the #, making it
harder to parse in scripts.
Of course, I'm only ever producing this, and never consuming, so if the
manual reading is fine for the stable developers, who am I to argue.
BR,
Jani.
> Following the submission:
>
> - The sender will receive an ACK when the patch has been accepted into the
--
Jani Nikula, Intel Open Source Graphics Center
On 10.07.23 21:51, Greg KH wrote:
> On Mon, Jul 10, 2023 at 07:10:10PM +0200, Thorsten Leemhuis wrote:
>> This is a RFC and a bit rough for now. I only set down to create the
>> first of the three patches. But while doing so I noticed a few things
>> that seemed odd for me with my background on writing and editing texts.
>> So I just quickly performed a few additional changes to fix those to see
>> if the stable team would appreciate them, as this document is clearly
>> their domain.
>>
>> If those changes or even the initial patch are not welcomed, I'll simply
>> drop them. I'd totally understand this, as texts like these are delicate
>> and it's easy to accidentlly change the intent or the meaning while
>> adjusting things in good faith.
>>
>> At the same time I might be willing to do a few more changes, if people
>> like the direction this takes and want a bit more fine tuning.
>
> I do like it, many thanks for taking the time to do this work, it's much
> appreciated.
>
> If you resend the first 2 as a non-RFC patch,
BTW: thx again for your uplifting feedback! And in case anyone missed
it, I send those two patches out yesterday here:
https://lore.kernel.org/all/[email protected]/
> the last one needs some more work as mentioned.
I have that one in a separate branch now and spitted into four patches;
the first three basically move text around, which results in a much
cleaner diff for the last patch that contains actual content changes.
While working on the latter I noticed one more thing:
```
.. warning::
The -stable-rc tree is a snapshot in time of the stable-queue
tree and
will change frequently, hence will be rebased often. It should
only be
used for testing purposes (e.g. to be consumed by CI systems).
```
That sounded a bit odd to me, as it will scare people away that want to
test stable -rc's using git; and I think it doesn't match current
practices. I'll thus likely change the text to something like this,
unless I'm missing something or someone has a better idea:
```
.. warning::
The branches in the -stable-rc tree are rebased each time a new -rc
is released, as they are created by taking the latest release and
applying the patches from the stable-queue on top.
```
Ciao, Thorsten
On Wed, Jul 12, 2023 at 11:30:30AM +0200, Thorsten Leemhuis wrote:
> On 10.07.23 21:51, Greg KH wrote:
> > On Mon, Jul 10, 2023 at 07:10:10PM +0200, Thorsten Leemhuis wrote:
> >> This is a RFC and a bit rough for now. I only set down to create the
> >> first of the three patches. But while doing so I noticed a few things
> >> that seemed odd for me with my background on writing and editing texts.
> >> So I just quickly performed a few additional changes to fix those to see
> >> if the stable team would appreciate them, as this document is clearly
> >> their domain.
> >>
> >> If those changes or even the initial patch are not welcomed, I'll simply
> >> drop them. I'd totally understand this, as texts like these are delicate
> >> and it's easy to accidentlly change the intent or the meaning while
> >> adjusting things in good faith.
> >>
> >> At the same time I might be willing to do a few more changes, if people
> >> like the direction this takes and want a bit more fine tuning.
> >
> > I do like it, many thanks for taking the time to do this work, it's much
> > appreciated.
> >
> > If you resend the first 2 as a non-RFC patch,
>
> BTW: thx again for your uplifting feedback! And in case anyone missed
> it, I send those two patches out yesterday here:
> https://lore.kernel.org/all/[email protected]/
>
> > the last one needs some more work as mentioned.
>
> I have that one in a separate branch now and spitted into four patches;
> the first three basically move text around, which results in a much
> cleaner diff for the last patch that contains actual content changes.
> While working on the latter I noticed one more thing:
>
> ```
> .. warning::
> The -stable-rc tree is a snapshot in time of the stable-queue
> tree and
> will change frequently, hence will be rebased often. It should
> only be
> used for testing purposes (e.g. to be consumed by CI systems).
> ```
>
> That sounded a bit odd to me, as it will scare people away that want to
> test stable -rc's using git;
They are only there for people who _DO_ want to test stable -rc's using
git.
> and I think it doesn't match current practices.
No, it's pretty correct, what does not match? It gets rebased all the
time.
> I'll thus likely
> change the text to something like this,
> unless I'm missing something or someone has a better idea:
> ```
> .. warning::
> The branches in the -stable-rc tree are rebased each time a new -rc
> is released, as they are created by taking the latest release and
> applying the patches from the stable-queue on top.
Yes, that is true, but they are also rebased sometimes in intermediate
places, before a -rc is released, just to give CI systems a chance to
test easier.
These are ONLY for CI systems to use, nothing else should be touching
them. So I think the current text is correct, what am I missing?
thanks,
greg k-h
On 12.07.23 17:16, Greg KH wrote:
> On Wed, Jul 12, 2023 at 11:30:30AM +0200, Thorsten Leemhuis wrote:
>> While working on the latter I noticed one more thing:
>>
>> ```
>> .. warning::
>> The -stable-rc tree is a snapshot in time of the stable-queue
>> tree and
>> will change frequently, hence will be rebased often. It should
>> only be
>> used for testing purposes (e.g. to be consumed by CI systems).
>> ```
> [...]
>> I'll thus likely
>> change the text to something like this,
>> unless I'm missing something or someone has a better idea:
>> ```
>> .. warning::
>> The branches in the -stable-rc tree are rebased each time a new -rc
>> is released, as they are created by taking the latest release and
>> applying the patches from the stable-queue on top.
>
> Yes, that is true, but they are also rebased sometimes in intermediate
> places, before a -rc is released, just to give CI systems a chance to
> test easier.
>
> These are ONLY for CI systems to use, nothing else should be touching
> them. So I think the current text is correct, what am I missing?
That I misunderstood things and forgot about the "rebased sometimes in
intermediate places" aspect I once knew about. Sorry. I'll leave the
text as it is then.
Nevertheless makes me wonder: is that strategy wise in times when some
ordinary users and some distributions are building kernels straight from
git repos instead of tarballs? I'm one of those, as I distribute
stable-rc packages for Fedora here:
https://copr.fedorainfracloud.org/groups/g/kernel-vanilla/coprs/
And the "rebased sometimes in intermediate places" aspect complicated
things for me (my scripts handle that and apparently I forgot about that
since I wrote them; uhhps :-/ ).
But whatever, not that important, feel free to ignore this remark. And I
can see why you are doing it the way you do, too.
Thx for you helpful feedback!
Ciao, Thorsten
On Wed, Jul 12, 2023 at 07:02:34PM +0200, Thorsten Leemhuis wrote:
> On 12.07.23 17:16, Greg KH wrote:
> > On Wed, Jul 12, 2023 at 11:30:30AM +0200, Thorsten Leemhuis wrote:
> >> While working on the latter I noticed one more thing:
> >>
> >> ```
> >> .. warning::
> >> The -stable-rc tree is a snapshot in time of the stable-queue
> >> tree and
> >> will change frequently, hence will be rebased often. It should
> >> only be
> >> used for testing purposes (e.g. to be consumed by CI systems).
> >> ```
> > [...]
> >> I'll thus likely
> >> change the text to something like this,
> >> unless I'm missing something or someone has a better idea:
> >> ```
> >> .. warning::
> >> The branches in the -stable-rc tree are rebased each time a new -rc
> >> is released, as they are created by taking the latest release and
> >> applying the patches from the stable-queue on top.
> >
> > Yes, that is true, but they are also rebased sometimes in intermediate
> > places, before a -rc is released, just to give CI systems a chance to
> > test easier.
> >
> > These are ONLY for CI systems to use, nothing else should be touching
> > them. So I think the current text is correct, what am I missing?
>
> That I misunderstood things and forgot about the "rebased sometimes in
> intermediate places" aspect I once knew about. Sorry. I'll leave the
> text as it is then.
>
> Nevertheless makes me wonder: is that strategy wise in times when some
> ordinary users and some distributions are building kernels straight from
> git repos instead of tarballs? I'm one of those, as I distribute
> stable-rc packages for Fedora here:
> https://copr.fedorainfracloud.org/groups/g/kernel-vanilla/coprs/
As we keep the patches in quilt, not git, it's the best we can do. The
-rc releases are never a straight-line if we have to do multiple ones,
we remove patches in the middle, add them at the end or beginning, and
sometimes even change existing ones.
All of this is stuff that a linear history tool like git can't really
model well, so we keep a quilt series of the patches in git for anyone
that want to generate the tree themselves, and we provide the -rc git
tree for those that don't want to generate it and can live with the
constant rebasing.
thanks,
greg k-h
On 12.07.23 21:00, Greg KH wrote:
> On Wed, Jul 12, 2023 at 07:02:34PM +0200, Thorsten Leemhuis wrote:
>> On 12.07.23 17:16, Greg KH wrote:
> [...]
>>>> .. warning::
>>>> The branches in the -stable-rc tree are rebased each time a new -rc
>>>> is released, as they are created by taking the latest release and
>>>> applying the patches from the stable-queue on top.
>>>
>>> Yes, that is true, but they are also rebased sometimes in intermediate
>>> places, before a -rc is released, just to give CI systems a chance to
>>> test easier.
> [...]
>> Nevertheless makes me wonder: is that strategy wise in times when some
>> ordinary users and some distributions are building kernels straight from
>> git repos instead of tarballs? I'm one of those, as I distribute
>> stable-rc packages for Fedora here:
>> https://copr.fedorainfracloud.org/groups/g/kernel-vanilla/coprs/
>
> As we keep the patches in quilt, not git, it's the best we can do. The
> -rc releases are never a straight-line if we have to do multiple ones,
> we remove patches in the middle, add them at the end or beginning, and
> sometimes even change existing ones.
>
> All of this is stuff that a linear history tool like git can't really
> model well, so we keep a quilt series of the patches in git for anyone
> that want to generate the tree themselves, and we provide the -rc git
> tree for those that don't want to generate it and can live with the
> constant rebasing.
/me first didn't want to reply, as this is not really important, but
then reconsidered; again, feel free to just ignore this
FWIW, I do not consider that rebasing to be problem at all; it are those
rebases "sometimes in intermediate places, before a -rc is released,
just to give CI systems a chance to test easier" make things this
slightly annoying bit harder when you want to distribute stable-rc
releases to users.
But as I said, I can fully understand why you do those as well. I just
with there was a way to reliably get a -rc release from git as well.
Simply tagging them when you do a -rc release would solve all that. Is
that maybe something that could be easily added to your -rc release scripts?
/me looks at https://github.com/gregkh/gregkh-linux/tree/master/stable
but failed to find the -rc release script :-/
Whatever, as I said, not really important. :-D Have a nice day everyone!
Ciao, Thorsten
On Thu, Jul 13, 2023 at 10:48:14AM +0200, Thorsten Leemhuis wrote:
> On 12.07.23 21:00, Greg KH wrote:
> > On Wed, Jul 12, 2023 at 07:02:34PM +0200, Thorsten Leemhuis wrote:
> >> On 12.07.23 17:16, Greg KH wrote:
> > [...]
> >>>> .. warning::
> >>>> The branches in the -stable-rc tree are rebased each time a new -rc
> >>>> is released, as they are created by taking the latest release and
> >>>> applying the patches from the stable-queue on top.
> >>>
> >>> Yes, that is true, but they are also rebased sometimes in intermediate
> >>> places, before a -rc is released, just to give CI systems a chance to
> >>> test easier.
> > [...]
> >> Nevertheless makes me wonder: is that strategy wise in times when some
> >> ordinary users and some distributions are building kernels straight from
> >> git repos instead of tarballs? I'm one of those, as I distribute
> >> stable-rc packages for Fedora here:
> >> https://copr.fedorainfracloud.org/groups/g/kernel-vanilla/coprs/
> >
> > As we keep the patches in quilt, not git, it's the best we can do. The
> > -rc releases are never a straight-line if we have to do multiple ones,
> > we remove patches in the middle, add them at the end or beginning, and
> > sometimes even change existing ones.
> >
> > All of this is stuff that a linear history tool like git can't really
> > model well, so we keep a quilt series of the patches in git for anyone
> > that want to generate the tree themselves, and we provide the -rc git
> > tree for those that don't want to generate it and can live with the
> > constant rebasing.
>
> /me first didn't want to reply, as this is not really important, but
> then reconsidered; again, feel free to just ignore this
>
> FWIW, I do not consider that rebasing to be problem at all; it are those
> rebases "sometimes in intermediate places, before a -rc is released,
> just to give CI systems a chance to test easier" make things this
> slightly annoying bit harder when you want to distribute stable-rc
> releases to users.
>
> But as I said, I can fully understand why you do those as well. I just
> with there was a way to reliably get a -rc release from git as well.
> Simply tagging them when you do a -rc release would solve all that. Is
> that maybe something that could be easily added to your -rc release scripts?
I can add a tag, but it would have to be a tag that can be rebased, and
git doesn't like that very well :)
> /me looks at https://github.com/gregkh/gregkh-linux/tree/master/stable
> but failed to find the -rc release script :-/
Hah, no github, it's at:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/scripts/quilt-mail
But I don't think tags will help much. I'll let anyone who actually
runs a CI that uses this to speak up to see if it would before adding
them.
Also, as proof this works, I just got a report of someone testing the
queues and finding a problem at the moment, before we sent anything out
for review. So this is working well today.
thanks,
greg k-h
On Thu, Jul 13, 2023 at 05:06:22PM +0200, Greg KH wrote:
> On Thu, Jul 13, 2023 at 10:48:14AM +0200, Thorsten Leemhuis wrote:
> > On 12.07.23 21:00, Greg KH wrote:
> > > On Wed, Jul 12, 2023 at 07:02:34PM +0200, Thorsten Leemhuis wrote:
> > >> On 12.07.23 17:16, Greg KH wrote:
> > > [...]
> > >>>> .. warning::
> > >>>> The branches in the -stable-rc tree are rebased each time a new -rc
> > >>>> is released, as they are created by taking the latest release and
> > >>>> applying the patches from the stable-queue on top.
> > >>>
> > >>> Yes, that is true, but they are also rebased sometimes in intermediate
> > >>> places, before a -rc is released, just to give CI systems a chance to
> > >>> test easier.
> > > [...]
> > >> Nevertheless makes me wonder: is that strategy wise in times when some
> > >> ordinary users and some distributions are building kernels straight from
> > >> git repos instead of tarballs? I'm one of those, as I distribute
> > >> stable-rc packages for Fedora here:
> > >> https://copr.fedorainfracloud.org/groups/g/kernel-vanilla/coprs/
> > >
> > > As we keep the patches in quilt, not git, it's the best we can do. The
> > > -rc releases are never a straight-line if we have to do multiple ones,
> > > we remove patches in the middle, add them at the end or beginning, and
> > > sometimes even change existing ones.
> > >
> > > All of this is stuff that a linear history tool like git can't really
> > > model well, so we keep a quilt series of the patches in git for anyone
> > > that want to generate the tree themselves, and we provide the -rc git
> > > tree for those that don't want to generate it and can live with the
> > > constant rebasing.
> >
> > /me first didn't want to reply, as this is not really important, but
> > then reconsidered; again, feel free to just ignore this
> >
> > FWIW, I do not consider that rebasing to be problem at all; it are those
> > rebases "sometimes in intermediate places, before a -rc is released,
> > just to give CI systems a chance to test easier" make things this
> > slightly annoying bit harder when you want to distribute stable-rc
> > releases to users.
> >
> > But as I said, I can fully understand why you do those as well. I just
> > with there was a way to reliably get a -rc release from git as well.
> > Simply tagging them when you do a -rc release would solve all that. Is
> > that maybe something that could be easily added to your -rc release scripts?
>
> I can add a tag, but it would have to be a tag that can be rebased, and
> git doesn't like that very well :)
I figure the desired tagging behaviour is that you do it when the email
is sent out for a corresponding version & so the tag "should" not need to
be rebased?
> > /me looks at https://github.com/gregkh/gregkh-linux/tree/master/stable
> > but failed to find the -rc release script :-/
>
> Hah, no github, it's at:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/scripts/quilt-mail
>
> But I don't think tags will help much. I'll let anyone who actually
> runs a CI that uses this to speak up to see if it would before adding
> them.
I'm not sure that it is particularly valuable to the usual flow of
testing what is about to come down the tracks, at least in my simple
case where I trigger it based on the -rc emails or whenever something
else interesting happens, like a patch being dropped that breaks the
build.
I suppose it may be useful if an issue presents itself but disappears
when a backport is dropped from the queue & some developers are
interested in figuring out why the backport went awry?
Other than that, I'm not sure what the value is in "I just with [sic]
there was a way to reliably get a -rc release from git as well", in
_my_ CI use case I don't care about the superseded stable -rc versions,
just whatever is about to be released.
Others with more complex CI infrastructure, like Linaro etc, might feel
differently :)
> Also, as proof this works, I just got a report of someone testing the
> queues and finding a problem at the moment, before we sent anything out
> for review. So this is working well today.
>
> thanks,
>
> greg k-h
On 13.07.23 17:39, Conor Dooley wrote:
> On Thu, Jul 13, 2023 at 05:06:22PM +0200, Greg KH wrote:
>> On Thu, Jul 13, 2023 at 10:48:14AM +0200, Thorsten Leemhuis wrote:
>>> On 12.07.23 21:00, Greg KH wrote:
>>>> On Wed, Jul 12, 2023 at 07:02:34PM +0200, Thorsten Leemhuis wrote:
>>>>> On 12.07.23 17:16, Greg KH wrote:
>>>> [...]
>>>>>>> .. warning::
>>>>>>> The branches in the -stable-rc tree are rebased each time a new -rc
>>>>>>> is released, as they are created by taking the latest release and
>>>>>>> applying the patches from the stable-queue on top.
>>>>>>
>>>>>> Yes, that is true, but they are also rebased sometimes in intermediate
>>>>>> places, before a -rc is released, just to give CI systems a chance to
>>>>>> test easier.
>>>> [...]
>>>>> Nevertheless makes me wonder: is that strategy wise in times when some
>>>>> ordinary users and some distributions are building kernels straight from
>>>>> git repos instead of tarballs? I'm one of those, as I distribute
>>>>> stable-rc packages for Fedora here:
>>>>> https://copr.fedorainfracloud.org/groups/g/kernel-vanilla/coprs/
>>>>
>>>> As we keep the patches in quilt, not git, it's the best we can do. The
>>>> -rc releases are never a straight-line if we have to do multiple ones,
>>>> we remove patches in the middle, add them at the end or beginning, and
>>>> sometimes even change existing ones.
>>>>
>>>> All of this is stuff that a linear history tool like git can't really
>>>> model well, so we keep a quilt series of the patches in git for anyone
>>>> that want to generate the tree themselves, and we provide the -rc git
>>>> tree for those that don't want to generate it and can live with the
>>>> constant rebasing.
>>>
>>> /me first didn't want to reply, as this is not really important, but
>>> then reconsidered; again, feel free to just ignore this
>>>
>>> FWIW, I do not consider that rebasing to be problem at all; it are those
>>> rebases "sometimes in intermediate places, before a -rc is released,
>>> just to give CI systems a chance to test easier" make things this
>>> slightly annoying bit harder when you want to distribute stable-rc
>>> releases to users.
>>>
>>> But as I said, I can fully understand why you do those as well. I just
>>> with there was a way to reliably get a -rc release from git as well.
>>> Simply tagging them when you do a -rc release would solve all that. Is
>>> that maybe something that could be easily added to your -rc release scripts?
>>
>> I can add a tag, but it would have to be a tag that can be rebased, and
>> git doesn't like that very well :)
>
> I figure the desired tagging behaviour is that you do it when the email
> is sent out for a corresponding version & so the tag "should" not need to
> be rebased?
Yup, exactly, that's what I meant, as that makes it possible to get the
same state as the tarball by simply doing a "git checkout v6.4.4-rc1",
even if the linux-6.4.y branch in the stable-rc repo changed.
And CI systems should not care.
>>> /me looks at https://github.com/gregkh/gregkh-linux/tree/master/stable
>>> but failed to find the -rc release script :-/
>>
>> Hah, no github, it's at:
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/scripts/quilt-mail
>>
>> But I don't think tags will help much. I'll let anyone who actually
>> runs a CI that uses this to speak up to see if it would before adding
>> them.
>
> I'm not sure that it is particularly valuable to the usual flow of
> testing what is about to come down the tracks, at least in my simple
> case where I trigger it based on the -rc emails
My scripts instead wait for the tarballs to show up on kernel.org. :-D
> or whenever something
> else interesting happens, like a patch being dropped that breaks the
> build.
>
> I suppose it may be useful if an issue presents itself but disappears
> when a backport is dropped from the queue & some developers are
> interested in figuring out why the backport went awry?
>
> Other than that, I'm not sure what the value is in "I just with [sic]
> there was a way to reliably get a -rc release from git as well", in
> _my_ CI use case I don't care about the superseded stable -rc versions,
> just whatever is about to be released.
>
> Others with more complex CI infrastructure, like Linaro etc, might feel
> differently :)
Yeah, CI systems likely don't care much, but I distribute the proper
stable-rc releases to ordinary users for simple testing in the wild; and
it afaics would be good if they'd match the tarball in case a users runs
into problems and reports them, as I fear people otherwise might quickly
talk past each other...
Ciao, Thorsten