From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: torvalds@linux-foundation.org, akpm@linux-foundation.org,
linux@roeck-us.net, shuah@kernel.org, patches@kernelci.org,
ben.hutchings@codethink.co.uk, lkft-triage@lists.linaro.org,
stable@vger.kernel.org, linux-tegra@vger.kernel.org
Subject: Re: [PATCH 5.2 00/20] 5.2.6-stable review
Date: Mon, 4 Jan 2021 13:39:28 +0100 [thread overview]
Message-ID: <X/MMgPChJ2C+85Tf@kroah.com> (raw)
In-Reply-To: <20190812090553.GA8903@ulmo>
On Mon, Aug 12, 2019 at 11:05:53AM +0200, Thierry Reding wrote:
> On Fri, Aug 09, 2019 at 05:49:59PM +0200, Greg Kroah-Hartman wrote:
> > On Fri, Aug 09, 2019 at 03:04:49PM +0200, Thierry Reding wrote:
> > > On Fri, Aug 09, 2019 at 10:52:53AM +0200, Greg Kroah-Hartman wrote:
> > > > On Mon, Aug 05, 2019 at 01:48:21PM +0200, Thierry Reding wrote:
> > > > > Hi Greg,
> > > >
> > > > Sorry for the delay, this got pushed down my queue...
> > > >
> > > > > I stumbled across something as I was attempting to automate more parts
> > > > > of our process to generate these reports. The original test results were
> > > > > from a different version of the tree: 5.2.6-rc1-gdbc7f5c7df28. I suspect
> > > > > that's the same thing that you were discussing with Pavel regarding the
> > > > > IP tunnel patch that was added subsequent to the announcement.
> > > > >
> > > > > Just for my understanding, does this mean that the patch still makes it
> > > > > into the 5.2.6 release, or was it supposed to go into 5.2.7?
> > > > >
> > > > > One problem that I ran into was that when I tried to correlate the test
> > > > > results with your announcement email, there's no indication other than
> > > > > the branch name and the release candidate name (5.2.6-rc1 in this case),
> > > > > so there's no way to uniquely identify which test run belongs to the
> > > > > announcement. Given that there are no tags for the release candidates
> > > > > means that that's also not an option to uniquely associate with the
> > > > > builds and tests.
> > > > >
> > > > > While the differences between the two builds are very minor here, I
> > > > > wonder if there could perhaps in the future be a problem where I report
> > > > > successful results for a test, but the same tests would be broken by a
> > > > > patch added to the stable-rc branch subsequent to the announcement. The
> > > > > test report would be misleading in that case.
> > > > >
> > > > > I noticed that you do add a couple of X-KernelTest-* headers to your
> > > > > announcement emails, so I'm wondering if perhaps it was possible for you
> > > > > to add another one that contains the exact SHA1 that corresponds to the
> > > > > snapshot that's the release candidate. That would allow everyone to
> > > > > uniquely associate test results with a specific release candidate.
> > > > >
> > > > > That said, perhaps I've just got this all wrong and there's already a
> > > > > way to connect all the dots that I'm not aware of. Or maybe I'm being
> > > > > too pedantic here?
> > > >
> > > > You aren't being pedantic, I think you are missing exactly what the
> > > > linux-stable-rc tree is for and how it is created.
> > > >
> > > > Granted, it's not really documented anywhere so it's not your fault :)
> > > >
> > > > The linux-stable-rc tree is there ONLY for people who want to test the
> > > > -rc kernels and can not, or do not want to, use the quilt tree of
> > > > patches in the stable-queue.git tree on kernel.org. I generate the
> > > > branches there from a script that throws away the current -rc branch and
> > > > rebuilds it "from scratch" by applying the patches that are in the
> > > > stable-quilt tree and then adds the -rc patch as well. This tree is
> > > > generated multiple times when I am working on the queues and then when I
> > > > want to do a "real" -rc release.
> > > >
> > > > The branches are constantly rebased, so you can not rely on 'git pull'
> > > > doing the right thing (unless you add --rebase to it), and are there for
> > > > testing only.
> > > >
> > > > Yes, you will see different results of a "-rc1" release in the tree
> > > > depending on the time of day/week when I created the tree, and sometimes
> > > > I generate them multiple times a day just to have some of the
> > > > auto-builders give me results quickly (Linaro does pull from it and
> > > > sends me results within the hour usually).
> > > >
> > > > So does that help? Ideally everyone would just use the quilt trees from
> > > > stable-queue.git, but no everyone likes that, so the -rc git tree is
> > > > there to make automated testing "easier". If that works with your
> > > > workflow, wonderful, feel free to use it. If not, then go with the
> > > > stable-quilt.git tree, or the tarballs on kernel.org.
> > >
> > > I'll have to look into that, to see if that'd work. I have to admit that
> > > having a git tree to point scripts at is rather convenient for
> > > automation.
> > >
> > > > And as for the SHA1 being in the emails, that doesn't make all that much
> > > > sense as that SHA1 doesn't live very long. When I create the trees
> > > > locally, I instantly delete them after pushing them to kernel.org so I
> > > > can't regenerate them or do anything with them.
> > >
> > > Fair enough. I suppose the worst thing that could happen is that we may
> > > fail to test a couple of commits occasionally. In the rare case where
> > > this actually matters we'll likely end up reporting the failure for the
> > > stable release, in which case it can be fixed in the next one.
> > >
> > > > DOes that help explain things better?
> > >
> > > Yes, makes a lot more sense now. Thanks for taking the time to explain
> > > it. Do you want me to snapshot this and submit it as documentation
> > > somewhere for later reference?
> >
> > It probably should go somewhere, but as the number of people that do
> > "test stable kernels in an automated way" is very low, so far I've been
> > doing ok with a one-by-one explaination. I guess if it's more obvious,
> > more people would test, so sure, this should be cleaned up...
>
> How about something like the below. It applies to the stable-queue.git
> repository.
>
> Thierry
>
> --- >8 ---
> From 4083add6ccb4a1c23edeba650170470bcc5d5205 Mon Sep 17 00:00:00 2001
> From: Thierry Reding <treding@nvidia.com>
> Date: Mon, 12 Aug 2019 10:58:35 +0200
> Subject: [PATCH] Describe the stable-queue release process
>
> Add a README file that describes how release candidates for stable
> kernels are created and how users are expected to use them. This is
> reworded from Greg's reply here:
>
> https://lore.kernel.org/stable/20190809085253.GA25046@kroah.com/
> ---
> README | 31 +++++++++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
> create mode 100644 README
>
> diff --git a/README b/README
> new file mode 100644
> index 000000000000..868469a73f68
> --- /dev/null
> +++ b/README
> @@ -0,0 +1,31 @@
> +This repository is the canonical source for patches that make up the stable
> +kernel releases. It consists of a set of directories for each of the stable
> +kernels, as well as a directory that contains a snapshot of the patches for
> +each stable release.
> +
> +The patches for each release can be found along with a complete tarball of
> +a release in the following location:
> +
> + https://kernel.org/pub/linux/kernel/vX.Y/
> +
> +For each stable release candidate, a patch representing the diff of all the
> +patches in the stable queue is uploaded here:
> +
> + https://kernel.org/pub/linux/kernel/vX.Y/stable-review/
> +
> +As a convenience for people that want to test release candidates of stable
> +releases, a branch of the kernel git tree is created containing all of the
> +patches in the given stable queue. These branches are available in the
> +following repository:
> +
> + git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> +
> +A branch exists for each of the stable releases. Note, though, that these
> +branches are recreated from scratch by applying the queued stable patches
> +on top of the prior release. As a consequence, the branches are not fast-
> +forward and can change after a release candidate has been announced. The
> +contents of the branch may therefore not match exactly what was released
> +as the release candidate, depending on when you fetch it. No tags are
> +created to track individual release candidates. If you're interested in
> +exact reproducibility of a stable release candidate, please use the patches
> +from the location mentioned above.
> --
Sorry for the very long delay, cleaning out old emails...
This looks really good, thanks for writing it up, I've now applied it to
the stable-queue tree.
greg k-h
next prev parent reply other threads:[~2021-01-04 12:38 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-02 9:39 [PATCH 5.2 00/20] 5.2.6-stable review Greg Kroah-Hartman
2019-08-02 9:39 ` [PATCH 5.2 01/20] vsock: correct removal of socket from the list Greg Kroah-Hartman
2019-08-02 9:39 ` [PATCH 5.2 02/20] ISDN: hfcsusb: checking idx of ep configuration Greg Kroah-Hartman
2019-08-02 9:39 ` [PATCH 5.2 03/20] ALSA: usb-audio: Sanity checks for each pipe and EP types Greg Kroah-Hartman
2019-08-02 13:48 ` Sasha Levin
2019-08-02 15:51 ` Greg Kroah-Hartman
2019-08-07 2:38 ` Sasha Levin
2019-08-02 9:39 ` [PATCH 5.2 04/20] bpf: fix NULL deref in btf_type_is_resolve_source_only Greg Kroah-Hartman
2019-08-02 9:39 ` [PATCH 5.2 05/20] media: au0828: fix null dereference in error path Greg Kroah-Hartman
2019-08-02 9:40 ` [PATCH 5.2 06/20] ath10k: Change the warning message string Greg Kroah-Hartman
2019-08-02 9:40 ` [PATCH 5.2 07/20] media: cpia2_usb: first wake up, then free in disconnect Greg Kroah-Hartman
2019-08-02 9:40 ` [PATCH 5.2 08/20] media: pvrusb2: use a different format for warnings Greg Kroah-Hartman
2019-08-02 9:40 ` [PATCH 5.2 09/20] NFS: Cleanup if nfs_match_client is interrupted Greg Kroah-Hartman
2019-08-02 9:40 ` [PATCH 5.2 10/20] media: radio-raremono: change devm_k*alloc to k*alloc Greg Kroah-Hartman
2019-08-02 10:04 ` Joe Perches
2019-08-06 5:34 ` Luke Nowakowski-Krijger
2019-08-02 9:40 ` [PATCH 5.2 11/20] xfrm: policy: fix bydst hlist corruption on hash rebuild Greg Kroah-Hartman
2019-08-02 9:40 ` [PATCH 5.2 12/20] nvme: fix multipath crash when ANA is deactivated Greg Kroah-Hartman
2019-08-02 9:40 ` [PATCH 5.2 13/20] Bluetooth: hci_uart: check for missing tty operations Greg Kroah-Hartman
2019-08-02 9:40 ` [PATCH 5.2 14/20] sched/fair: Dont free p->numa_faults with concurrent readers Greg Kroah-Hartman
2019-08-02 9:40 ` [PATCH 5.2 15/20] sched/fair: Use RCU accessors consistently for ->numa_group Greg Kroah-Hartman
2019-08-02 9:40 ` [PATCH 5.2 16/20] /proc/<pid>/cmdline: remove all the special cases Greg Kroah-Hartman
2019-08-02 9:40 ` [PATCH 5.2 17/20] /proc/<pid>/cmdline: add back the setproctitle() special case Greg Kroah-Hartman
2019-08-02 9:40 ` [PATCH 5.2 18/20] drivers/pps/pps.c: clear offset flags in PPS_SETPARAMS ioctl Greg Kroah-Hartman
2019-08-02 9:40 ` [PATCH 5.2 19/20] Fix allyesconfig output Greg Kroah-Hartman
2019-08-02 9:40 ` [PATCH 5.2 20/20] ceph: hold i_ceph_lock when removing caps for freeing inode Greg Kroah-Hartman
2019-08-02 17:21 ` [PATCH 5.2 00/20] 5.2.6-stable review Thierry Reding
2019-08-03 7:09 ` Greg Kroah-Hartman
2019-08-05 11:48 ` Thierry Reding
2019-08-09 8:52 ` Greg Kroah-Hartman
2019-08-09 13:04 ` Thierry Reding
2019-08-09 15:49 ` Greg Kroah-Hartman
2019-08-12 9:05 ` Thierry Reding
2021-01-04 12:39 ` Greg Kroah-Hartman [this message]
2019-08-02 23:25 ` shuah
2019-08-03 7:08 ` Greg Kroah-Hartman
2019-08-03 5:50 ` Naresh Kamboju
2019-08-03 7:11 ` Greg Kroah-Hartman
2019-08-03 16:00 ` Guenter Roeck
2019-08-04 7:15 ` Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=X/MMgPChJ2C+85Tf@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=akpm@linux-foundation.org \
--cc=ben.hutchings@codethink.co.uk \
--cc=linux-tegra@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=lkft-triage@lists.linaro.org \
--cc=patches@kernelci.org \
--cc=shuah@kernel.org \
--cc=stable@vger.kernel.org \
--cc=thierry.reding@gmail.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).