On Tue, Jun 30, 2020 at 05:33:25PM +0200, Greg Kroah-Hartman wrote:
On Tue, Jun 30, 2020 at 11:12:48AM -0400, Sasha Levin wrote:
On Tue, Jun 30, 2020 at 10:38:45AM +0200, Greg Kroah-Hartman wrote:
On Mon, Jun 29, 2020 at 07:18:26PM -0400, Sasha Levin wrote:
On Mon, Jun 29, 2020 at 02:37:53PM -0600, Shuah Khan wrote:
Hi Sasha,
On 6/29/20 9:13 AM, Sasha Levin wrote:
This is the start of the stable review cycle for the 5.7.7 release. There are 265 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed 01 Jul 2020 03:14:48 PM UTC. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/p...
Looks like patch naming convention has changed. My scripts look for the following convention Greg uses. Are you planning to use the above going forward? My scripts failed looking for the usual naming convention.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.7.6-rc1.g... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.7.y and the diffstat can be found below.
Sorry for that. I was hoping to avoid using the signed upload mechanism Greg was using by simply pointing the links to automatically generated patches on cgit (the git.kernel.org interface).
Would it be ok to change the pattern matching here? Something like this should work for both Greg's format and my own (and whatever may come next):
grep -A1 "The whole patch series can be found in one patch at:" | tail -n1 | sed 's/\t//'
If those don't work, I can still push out -rc1 patches.
It might be best given that the above -rc.git tree is unstable and can, and will, change, and patches stored on kernel.org will not.
That's a good point. Maybe we should push tags for -rc releases too? that would allow us to keep stable links using the git.kernel.org interface.
If we really want to do this, then yes, we could. But that kind of goes against what we (well I) have been doing in the past with that tree...
We've been force pushing it, yes, but if we add tags it would just keep older version around so I don't think it would change much for our workflow, but it would make it easy to get to older versions.