stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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: Fri, 9 Aug 2019 15:04:49 +0200	[thread overview]
Message-ID: <20190809130449.GA27957@ulmo> (raw)
In-Reply-To: <20190809085253.GA25046@kroah.com>

[-- Attachment #1: Type: text/plain, Size: 4690 bytes --]

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?

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2019-08-09 13:04 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 [this message]
2019-08-09 15:49           ` Greg Kroah-Hartman
2019-08-12  9:05             ` Thierry Reding
2021-01-04 12:39               ` Greg Kroah-Hartman
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=20190809130449.GA27957@ulmo \
    --to=thierry.reding@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=ben.hutchings@codethink.co.uk \
    --cc=gregkh@linuxfoundation.org \
    --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=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).