On Sat, Jul 14, 2018 at 11:09:13PM +0200, Pavel Machek wrote:
> > For anyone interested in making sure that obscure (whatever that means)
> > drivers are tested for stable releases, but does not want to spend time on
> > it,
> > all I can recommend is to implement qemu support for it and let me kn
Hi!
> >Well, 0day, kernelci etc... is nice... until the change is in the
> >driver. Most of the kernel are drivers, remember?
> >
> >I don't know. I'd say that if patch is important enough for -stable,
> >there should be someone testing it. For core kernel changes, that can
> >be 0day bot, but for
On 07/14/2018 12:47 PM, Pavel Machek wrote:
Hi!
The way I see it, if a commit can get one or two tested-by, it's a good
alternative to a week in -next.
Agreed. Even their own actually. And I'm not kidding. Those who run large
amounts of tests on certain patches could really mention is in test
Hi!
> >>>The way I see it, if a commit can get one or two tested-by, it's a good
> >>>alternative to a week in -next.
> >>
> >>Agreed. Even their own actually. And I'm not kidding. Those who run large
> >>amounts of tests on certain patches could really mention is in tested-by,
> >>as opposed to t
On 07/14/2018 10:38 AM, Pavel Machek wrote:
Hi!
The way I see it, if a commit can get one or two tested-by, it's a good
alternative to a week in -next.
Agreed. Even their own actually. And I'm not kidding. Those who run large
amounts of tests on certain patches could really mention is in test
On Mon, May 14, 2018 at 10:36:04AM +0200, Ulf Hansson wrote:
> I will ping the kernelci folkz to request them to include your new
> fixes branch for daily builds.
No need, I already added it.
signature.asc
Description: PGP signature
Hi Krzysztof,
On Tue, 15 May 2018 12:42:49 +0200 Krzysztof Kozlowski wrote:
>
> Please merge following fixes branches from my trees:
> Tree: samsung-krzk
> git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git
> branch: fixes
>
> Tree: pinctrl-samsung
> git://git.kernel.org/pub/scm/linux/
On Wed, May 9, 2018 at 2:43 PM, Stephen Rothwell wrote:
> Hi Vinod,
>
> On Wed, 9 May 2018 16:25:34 +0530 Vinod Koul wrote:
>> >
>> > I currently have 44 such fixes branches. More welcome!
>>
>> Great so do you want us to send fixes branch or scan the existing trees and
>> add
>> them.
>
> The
Hi Ulf,
On Mon, 14 May 2018 10:36:04 +0200 Ulf Hansson wrote:
>
> I will ping the kernelci folkz to request them to include your new
> fixes branch for daily builds.
Excellent, thanks.
> For mmc, please add my fixes branch according to below.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/u
On Mon, May 14, 2018 at 10:48:03AM +0200, Boris Brezillon wrote:
+Fengguang
On Mon, 14 May 2018 10:40:10 +0200
Geert Uytterhoeven wrote:
Hi Boris,
On Mon, May 14, 2018 at 10:34 AM, Boris Brezillon
wrote:
> On Mon, 14 May 2018 10:29:04 +0200
> Geert Uytterhoeven wrote:
>> On Mon, May 14, 20
+Fengguang
On Mon, 14 May 2018 10:40:10 +0200
Geert Uytterhoeven wrote:
> Hi Boris,
>
> On Mon, May 14, 2018 at 10:34 AM, Boris Brezillon
> wrote:
> > On Mon, 14 May 2018 10:29:04 +0200
> > Geert Uytterhoeven wrote:
> >> On Mon, May 14, 2018 at 10:12 AM, Boris Brezillon
> >> wrote:
> >>
Hi Boris,
On Mon, May 14, 2018 at 10:34 AM, Boris Brezillon
wrote:
> On Mon, 14 May 2018 10:29:04 +0200
> Geert Uytterhoeven wrote:
>> On Mon, May 14, 2018 at 10:12 AM, Boris Brezillon
>> wrote:
>> > On Mon, 14 May 2018 10:00:30 +0200
>> > Geert Uytterhoeven wrote:
>> >> On Tue, May 1, 2018 at
On 9 May 2018 at 12:47, Stephen Rothwell wrote:
> On Wed, 9 May 2018 18:03:46 +0900 Mark Brown wrote:
>>
>> On Wed, May 09, 2018 at 10:47:57AM +0200, Daniel Vetter wrote:
>> > On Wed, May 9, 2018 at 10:44 AM, Mark Brown wrote:
>>
>> > > I think this is an excellent idea, copying in Stephen for h
On Mon, 14 May 2018 10:29:04 +0200
Geert Uytterhoeven wrote:
> Hi Boris,
>
> On Mon, May 14, 2018 at 10:12 AM, Boris Brezillon
> wrote:
> > On Mon, 14 May 2018 10:00:30 +0200
> > Geert Uytterhoeven wrote:
> >> On Tue, May 1, 2018 at 10:00 PM, Sasha Levin
> >> wrote:
> >> > On Tue, May 01,
Hi Boris,
On Mon, May 14, 2018 at 10:12 AM, Boris Brezillon
wrote:
> On Mon, 14 May 2018 10:00:30 +0200
> Geert Uytterhoeven wrote:
>> On Tue, May 1, 2018 at 10:00 PM, Sasha Levin
>> wrote:
>> > On Tue, May 01, 2018 at 03:44:50PM -0400, Theodore Y. Ts'o wrote:
>> >>On Tue, May 01, 2018 at 04:38
On Mon, 14 May 2018 10:00:30 +0200
Geert Uytterhoeven wrote:
> On Tue, May 1, 2018 at 10:00 PM, Sasha Levin
> wrote:
> > On Tue, May 01, 2018 at 03:44:50PM -0400, Theodore Y. Ts'o wrote:
> >>On Tue, May 01, 2018 at 04:38:21PM +, Sasha Levin wrote:
> >>> - A merge window commit spent 50%
On Thu, May 10, 2018 at 6:47 PM, Sasha Levin via Ksummit-discuss
wrote:
> On Thu, May 10, 2018 at 06:03:22PM +0200, Jiri Kosina wrote:
>>On Wed, 9 May 2018, Daniel Vetter wrote:
>>> >> Then, why don't we have a pre-integration tree for fixes? That would
>>> >> at least simply automated testing of
On Sat, May 12, 2018 at 7:38 AM, Stephen Rothwell wrote:
> Hi all,
>
> On Wed, 9 May 2018 20:47:27 +1000 Stephen Rothwell
> wrote:
>>
>> On Wed, 9 May 2018 18:03:46 +0900 Mark Brown wrote:
>> >
>> > On Wed, May 09, 2018 at 10:47:57AM +0200, Daniel Vetter wrote:
>> > > On Wed, May 9, 2018 at 10:
On 05/11/2018 09:38 PM, Stephen Rothwell wrote:
Hi all,
On Wed, 9 May 2018 20:47:27 +1000 Stephen Rothwell
wrote:
On Wed, 9 May 2018 18:03:46 +0900 Mark Brown wrote:
On Wed, May 09, 2018 at 10:47:57AM +0200, Daniel Vetter wrote:
On Wed, May 9, 2018 at 10:44 AM, Mark Brown wrote:
I
Hi all,
On Wed, 9 May 2018 20:47:27 +1000 Stephen Rothwell
wrote:
>
> On Wed, 9 May 2018 18:03:46 +0900 Mark Brown wrote:
> >
> > On Wed, May 09, 2018 at 10:47:57AM +0200, Daniel Vetter wrote:
> > > On Wed, May 9, 2018 at 10:44 AM, Mark Brown wrote:
> > >
> >
> > > > I think this is
Hi David,
On Fri, 11 May 2018 10:47:01 +0200 David Sterba wrote:
>
> Please add
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git next-fixes
Added from Monday (as btrfs-fixes).
Thanks for adding your subsystem tree as a participant of linux-next. As
you may know, this is not
On Wed, May 09, 2018 at 08:47:27PM +1000, Stephen Rothwell wrote:
> > True. It's currently only those -fixes branches that people have asked
> > him to merge separately which isn't as big a proportion of trees as have
> > them (perhaps fortunately given people's enthusiasm for fixes branches
> > t
On Thu, May 10, 2018 at 06:03:22PM +0200, Jiri Kosina wrote:
> On Wed, 9 May 2018, Daniel Vetter wrote:
> > Since Stephen merges all -fixes branches first, before merging all the
> > -next branches, he already generates that as part of linux-next. All
> > he'd need to do is push that intermediate
Hi Tony,
On Thu, 10 May 2018 08:57:55 -0700 Tony Lindgren wrote:
>
> * Stephen Rothwell [180509 10:49]:
> > I currently have 44 such fixes branches. More welcome!
>
> Can you please also add mine:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git fixes
Added from toda
Hi Mark,
On Thu, 10 May 2018 22:36:28 +0900 Mark Brown wrote:
>
> On Thu, May 10, 2018 at 08:09:09AM +1000, Stephen Rothwell wrote:
> > On Wed, 9 May 2018 23:05:32 +0900 Mark Brown wrote:
>
> > > Well, all my trees have a for-linus branch to go with the for-next
> > > branch for a start.
>
On Thu, May 10, 2018 at 06:03:22PM +0200, Jiri Kosina wrote:
>On Wed, 9 May 2018, Daniel Vetter wrote:
>
>> >> Then, why don't we have a pre-integration tree for fixes? That would
>> >> at least simply automated testing of fixes separately from new
>> >> material.
>> >
>> >> Perhaps this has alread
On Tue, May 08, 2018 at 06:15:34PM -0400, Theodore Y. Ts'o wrote:
>On Tue, May 08, 2018 at 08:29:14PM +, Sasha Levin wrote:
>>
>> This is interesting. We have a group of power users who are testing out
>> -rc releases, who are usually happy to test out a fast moving target and
>> provide helpfu
On Wed, 9 May 2018, Daniel Vetter wrote:
> >> Then, why don't we have a pre-integration tree for fixes? That would
> >> at least simply automated testing of fixes separately from new
> >> material.
> >
> >> Perhaps this has already been discussed, and concluded and it's not
> >> worth it, then apo
* Stephen Rothwell [180509 10:49]:
> I currently have 44 such fixes branches. More welcome!
Can you please also add mine:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git fixes
Thanks,
Tony
signature.asc
Description: PGP signature
* Tony Lindgren [180508 14:52]:
> * Theodore Y. Ts'o [180508 03:50]:
> > Would I pull down linux-next, and fire up a VM running gce-xfstests?
> > Sure. But that's not a real-life use case; that's just running canned
> > test cases. And more often than not, linux-next will be broken while
> > Li
On Thu, May 10, 2018 at 08:09:09AM +1000, Stephen Rothwell wrote:
> On Wed, 9 May 2018 23:05:32 +0900 Mark Brown wrote:
> > Well, all my trees have a for-linus branch to go with the for-next
> > branch for a start.
> The regmap and regulator trees have no for-linus branch (currently).
> Added so
On Wed, May 09, 2018 at 08:47:27PM +1000, Stephen Rothwell wrote:
>On Wed, 9 May 2018 18:03:46 +0900 Mark Brown wrote:
>>
>> On Wed, May 09, 2018 at 10:47:57AM +0200, Daniel Vetter wrote:
>> > On Wed, May 9, 2018 at 10:44 AM, Mark Brown wrote:
>>
>> > > I think this is an excellent idea, copying
Hi Mark,
On Wed, 9 May 2018 23:05:32 +0900 Mark Brown wrote:
>
> Well, all my trees have a for-linus branch to go with the for-next
> branch for a start.
The regmap and regulator trees have no for-linus branch (currently).
Added sound-asoc-fixes and spi-fixes from today.
Thanks for adding your
Hi Boris,
On Wed, 9 May 2018 21:35:28 +0200 Boris Brezillon
wrote:
>
> I see that the nand/fixes and spi-nor/fixes branch are already there [1].
> You can add:
>
> mtd-fixes git git://git.infradead.org/linux-mtd.git#master
Added from today.
> You can also remove the mtd entry [2], sin
Hi Dan,
On Wed, 9 May 2018 09:04:31 -0700 Dan Williams wrote:
>
> Please add:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git
> libnvdimm-fixes
>
> We currently merge this into libnvdimm-for-next for -next coverage,
> and resolve any conflicts vs new development. Do you
Hi Guenter,
On Wed, 9 May 2018 08:57:33 -0700 Guenter Roeck wrote:
>
> Please add
>
> git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git hwmon
>
> as fixes branch.
Added from today.
Thanks for adding your subsystem tree as a participant of linux-next. As
you may know, thi
Hi Stephen,
On Wed, 9 May 2018 20:47:27 +1000
Stephen Rothwell wrote:
> On Wed, 9 May 2018 18:03:46 +0900 Mark Brown wrote:
> >
> > On Wed, May 09, 2018 at 10:47:57AM +0200, Daniel Vetter wrote:
> > > On Wed, May 9, 2018 at 10:44 AM, Mark Brown wrote:
> > >
> >
> > > > I think this i
On Wed, May 9, 2018 at 3:47 AM, Stephen Rothwell wrote:
> On Wed, 9 May 2018 18:03:46 +0900 Mark Brown wrote:
>>
>> On Wed, May 09, 2018 at 10:47:57AM +0200, Daniel Vetter wrote:
>> > On Wed, May 9, 2018 at 10:44 AM, Mark Brown wrote:
>>
>> > > I think this is an excellent idea, copying in Steph
On Wed, May 09, 2018 at 08:47:27PM +1000, Stephen Rothwell wrote:
> On Wed, 9 May 2018 18:03:46 +0900 Mark Brown wrote:
> >
> > On Wed, May 09, 2018 at 10:47:57AM +0200, Daniel Vetter wrote:
> > > On Wed, May 9, 2018 at 10:44 AM, Mark Brown wrote:
> >
> > > > I think this is an excellent idea,
On Wed, May 09, 2018 at 08:47:27PM +1000, Stephen Rothwell wrote:
> On Wed, 9 May 2018 18:03:46 +0900 Mark Brown wrote:
> > On Wed, May 09, 2018 at 10:47:57AM +0200, Daniel Vetter wrote:
> > > On Wed, May 9, 2018 at 10:44 AM, Mark Brown wrote:
> > True. It's currently only those -fixes branch
On 09-05-18, 22:43, Stephen Rothwell wrote:
> Hi Vinod,
>
> On Wed, 9 May 2018 16:25:34 +0530 Vinod Koul wrote:
> > >
> > > I currently have 44 such fixes branches. More welcome!
> >
> > Great so do you want us to send fixes branch or scan the existing trees and
> > add
> > them.
>
> The f
Hi Vinod,
On Wed, 9 May 2018 16:25:34 +0530 Vinod Koul wrote:
> >
> > I currently have 44 such fixes branches. More welcome!
>
> Great so do you want us to send fixes branch or scan the existing trees and
> add
> them.
The former.
> In case of former please do add slave-dma/fixes as well
On 09-05-18, 20:47, Stephen Rothwell wrote:
> On Wed, 9 May 2018 18:03:46 +0900 Mark Brown wrote:
> >
> > On Wed, May 09, 2018 at 10:47:57AM +0200, Daniel Vetter wrote:
> > > On Wed, May 9, 2018 at 10:44 AM, Mark Brown wrote:
> >
> > > > I think this is an excellent idea, copying in Stephen fo
On Wed, 9 May 2018 18:03:46 +0900 Mark Brown wrote:
>
> On Wed, May 09, 2018 at 10:47:57AM +0200, Daniel Vetter wrote:
> > On Wed, May 9, 2018 at 10:44 AM, Mark Brown wrote:
>
> > > I think this is an excellent idea, copying in Stephen for his input.
> > > I'm currently on holiday but unless s
On Wed, May 09, 2018 at 10:47:57AM +0200, Daniel Vetter wrote:
> On Wed, May 9, 2018 at 10:44 AM, Mark Brown wrote:
> > I think this is an excellent idea, copying in Stephen for his input.
> > I'm currently on holiday but unless someone convinces me it's a terrible
> > idea I'm willing to at leas
On Wed, May 9, 2018 at 10:47 AM, Daniel Vetter wrote:
> On Wed, May 9, 2018 at 10:44 AM, Mark Brown wrote:
>> On Fri, May 04, 2018 at 04:21:26PM +0200, Ulf Hansson wrote:
>>> Then, why don't we have a pre-integration tree for fixes? That would
>>> at least simply automated testing of fixes separa
On Wed, May 9, 2018 at 10:44 AM, Mark Brown wrote:
> On Fri, May 04, 2018 at 04:21:26PM +0200, Ulf Hansson wrote:
>
>> Then, why don't we have a pre-integration tree for fixes? That would
>> at least simply automated testing of fixes separately from new
>> material.
>
>> Perhaps this has already b
On Fri, May 04, 2018 at 04:21:26PM +0200, Ulf Hansson wrote:
> Then, why don't we have a pre-integration tree for fixes? That would
> at least simply automated testing of fixes separately from new
> material.
> Perhaps this has already been discussed, and concluded and it's not
> worth it, then a
On Tue, May 08, 2018 at 07:49:59AM -0700, Tony Lindgren wrote:
> * Theodore Y. Ts'o [180508 03:50]:
> > The people who run Linus's tree and test -rc kernels tend to be kernel
> > developers and individual users who want to run bleeding edge kernels
> > and who generally are technically clueful.
On Tue, May 08, 2018 at 08:29:14PM +, Sasha Levin wrote:
> What if, instead, Linus doesn't actually ever release a point release?
> We can make the merge window open more often, and since there's no
> actual release, people won't rush to push fixes in later -rc cycles.
And then what's the purp
On Tue, 2018-05-08 at 21:43 +, Sasha Levin via Ksummit-discuss
wrote:
> On Tue, May 08, 2018 at 01:59:18PM -0700, David Lang wrote:
> > On Tue, 8 May 2018, Sasha Levin wrote:
> >
> > > There's no one, for example, who picked up vanilla v4.16 and
> > > plans to keep using it for a year.
> >
>
On Tue, May 08, 2018 at 08:29:14PM +, Sasha Levin wrote:
>
> This is interesting. We have a group of power users who are testing out
> -rc releases, who are usually happy to test out a fast moving target and
> provide helpful reports back. We also have a group who run a -stable
> kernel (-stab
On Tue, May 8, 2018 at 2:43 PM, Sasha Levin via Ksummit-discuss
wrote:
> On Tue, May 08, 2018 at 01:59:18PM -0700, David Lang wrote:
>>On Tue, 8 May 2018, Sasha Levin wrote:
>>
>>>There's no one, for example, who picked up vanilla v4.16 and plans to
>>>keep using it for a year.
>>
>>Actually, at a
On Tue, May 08, 2018 at 01:59:18PM -0700, David Lang wrote:
>On Tue, 8 May 2018, Sasha Levin wrote:
>
>>There's no one, for example, who picked up vanilla v4.16 and plans to
>>keep using it for a year.
>
>Actually, at a prior job I would do almost exactly that.
>
>I never intended to go a year with
On Tue, May 8, 2018 at 3:55 PM, Sasha Levin
wrote:
> On Tue, May 08, 2018 at 08:40:02PM +, Matthew Wilcox wrote:
>>I think your sample size omits some people. I run Debian Testing on my
>>laptop. That gets something akin to a Linus release pretty soon after he
>>releases it, and while it gets
On 8 May 2018 at 21:29, Sasha Levin wrote:
>
> This is interesting. We have a group of power users who are testing out
> -rc releases, who are usually happy to test out a fast moving target and
> provide helpful reports back. We also have a group who run a -stable
> kernel (-stable build/distro/a
On Tue, 8 May 2018, Sasha Levin wrote:
There's no one, for example, who picked up vanilla v4.16 and plans to
keep using it for a year.
Actually, at a prior job I would do almost exactly that.
I never intended to go a year without updating, but it would happen if nothing
came up that was rela
On Tue, May 08, 2018 at 08:40:02PM +, Matthew Wilcox wrote:
>I think your sample size omits some people. I run Debian Testing on my
>laptop. That gets something akin to a Linus release pretty soon after he
>releases it, and while it gets some amount of -stable patches, it
>progresses to the nex
On Mon, May 07, 2018 at 11:48:20PM -0400, Theodore Y. Ts'o wrote:
>On Tue, May 08, 2018 at 02:34:41AM +, Sasha Levin via Ksummit-discuss
>wrote:
>>
>> Tony, I'm curious, how many users are you aware of who actually run
>> Linus's tree? All the users I've encountered so far on Azure seem to be
* Theodore Y. Ts'o [180508 03:50]:
> On Tue, May 08, 2018 at 02:34:41AM +, Sasha Levin via Ksummit-discuss
> wrote:
> >
> > Tony, I'm curious, how many users are you aware of who actually run
> > Linus's tree? All the users I've encountered so far on Azure seem to be
> > running something ba
On Mon, May 7, 2018 at 9:34 PM, Sasha Levin
wrote:
> On Thu, May 03, 2018 at 04:09:05PM -0700, Tony Lindgren wrote:
>>* Mark Brown [180503 22:44]:
>>> On Wed, May 02, 2018 at 08:52:29PM -0700, Guenter Roeck wrote:
>>>
>>> > As for -next, me and others stopped reporting bugs in it, because when we
On Tue, May 08, 2018 at 02:34:41AM +, Sasha Levin via Ksummit-discuss wrote:
>
> Tony, I'm curious, how many users are you aware of who actually run
> Linus's tree? All the users I've encountered so far on Azure seem to be
> running something based on -stable.
The people who run Linus's tree
On Fri, May 04, 2018 at 07:42:17AM +0900, Mark Brown wrote:
>On Wed, May 02, 2018 at 08:52:29PM -0700, Guenter Roeck wrote:
>
>> As for -next, me and others stopped reporting bugs in it, because when we do
>> we tend to get flamed for the "noise". Is anyone aware (or cares) that mips
>> and nds32 i
On Thu, May 03, 2018 at 04:09:05PM -0700, Tony Lindgren wrote:
>* Mark Brown [180503 22:44]:
>> On Wed, May 02, 2018 at 08:52:29PM -0700, Guenter Roeck wrote:
>>
>> > As for -next, me and others stopped reporting bugs in it, because when we
>> > do
>> > we tend to get flamed for the "noise". Is a
On Sat, May 05, 2018 at 12:02:47AM -0500, Eric W. Biederman wrote:
> So the way I use headers today is:
> Cc: sta...@vger.kernel.org
> Fixes: sha1hash "commit subject"
And that makes my life _so_ much easier. The Fixes: tag is great
(thanks James!), I have scripts that I use to track if a fix was
On Fri, May 04, 2018 at 07:35:42PM -0400, Theodore Y. Ts'o wrote:
>On Fri, May 04, 2018 at 09:51:14PM +, Sasha Levin wrote:
>> I don't have an objection to moving this to it's own tag. It will make
>> my scripts somewhat simpler for sure.
>
>It's not a matter "moving this it's own tag", but cre
Willy Tarreau writes:
> On Fri, May 04, 2018 at 07:35:42PM -0400, Theodore Y. Ts'o wrote:
>> On Fri, May 04, 2018 at 09:51:14PM +, Sasha Levin wrote:
>> > I don't have an objection to moving this to it's own tag. It will make
>> > my scripts somewhat simpler for sure.
>>
>> It's not a matter
On Fri, May 04, 2018 at 07:35:42PM -0400, Theodore Y. Ts'o wrote:
> On Fri, May 04, 2018 at 09:51:14PM +, Sasha Levin wrote:
> > I don't have an objection to moving this to it's own tag. It will make
> > my scripts somewhat simpler for sure.
>
> It's not a matter "moving this it's own tag", bu
On Fri, May 04, 2018 at 09:51:14PM +, Sasha Levin wrote:
> I don't have an objection to moving this to it's own tag. It will make
> my scripts somewhat simpler for sure.
It's not a matter "moving this it's own tag", but creating a new tag
--- because what is in the docs is a lie. It does not
On Fri, May 04, 2018 at 02:38:01PM -0700, James Bottomley wrote:
>On Fri, 2018-05-04 at 17:13 -0400, Theodore Y. Ts'o wrote:
>> If it's not necessary, fine. But we should still delete what is
>> currently documented in stable_kernel_rules and was introduced in
>> 8e9b9362266d, because it doesn't d
On Fri, 2018-05-04 at 17:13 -0400, Theodore Y. Ts'o wrote:
> If it's not necessary, fine. But we should still delete what is
> currently documented in stable_kernel_rules and was introduced in
> 8e9b9362266d, because it doesn't describe current practice.
It definitely doesn't seem to describe cur
On Fri, May 04, 2018 at 10:40:55AM -0700, Greg KH wrote:
> Ugh, what? I don't understand what you are proposing here, what we have
> today is just fine, what is broken with it?
What we have today is this:
Cc: sta...@kernel.org # 3.11
Cc: sta...@kernel.org # 4.8+
Cc: sta...@kernel.
On Fri, May 04, 2018 at 09:09:32AM -0400, Theodore Y. Ts'o wrote:
> On Fri, May 04, 2018 at 03:31:17PM +0300, Jani Nikula wrote:
> > On Fri, 04 May 2018, David Howells wrote:
> > > Sasha Levin via Ksummit-discuss wrote:
> > >
> > >> Cc: sta...@vger.kernel.org # commit-id-of-(2)
> >
> > This has b
Tony, Sasha, Mark
On 4 May 2018 at 01:09, Tony Lindgren wrote:
> * Mark Brown [180503 22:44]:
>> On Wed, May 02, 2018 at 08:52:29PM -0700, Guenter Roeck wrote:
>>
>> > As for -next, me and others stopped reporting bugs in it, because when we
>> > do
>> > we tend to get flamed for the "noise". I
On Fri, May 04, 2018 at 03:31:17PM +0300, Jani Nikula wrote:
> On Fri, 04 May 2018, David Howells wrote:
> > Sasha Levin via Ksummit-discuss wrote:
> >
> >>Cc: sta...@vger.kernel.org # commit-id-of-(2)
>
> This has been documented since
>
> commit 8e9b9362266dd16255473c080d846b13e27247bf
> Au
On Fri, 04 May 2018, David Howells wrote:
> Sasha Levin via Ksummit-discuss wrote:
>
>> Cc: sta...@vger.kernel.org # commit-id-of-(2)
>
> Can you please not do this? This screws up email address parsing in some
> tools.
This has been documented since
commit 8e9b9362266dd16255473c080d846b13
Sasha Levin via Ksummit-discuss wrote:
> Cc: sta...@vger.kernel.org # commit-id-of-(2)
Can you please not do this? This screws up email address parsing in some
tools.
David
* Mark Brown [180503 22:44]:
> On Wed, May 02, 2018 at 08:52:29PM -0700, Guenter Roeck wrote:
>
> > As for -next, me and others stopped reporting bugs in it, because when we do
> > we tend to get flamed for the "noise". Is anyone aware (or cares) that mips
> > and nds32 images don't build ? Soaki
On Wed, May 02, 2018 at 08:52:29PM -0700, Guenter Roeck wrote:
> As for -next, me and others stopped reporting bugs in it, because when we do
> we tend to get flamed for the "noise". Is anyone aware (or cares) that mips
> and nds32 images don't build ? Soaking clothes in an empty bathtub won't mak
On Thu, May 03, 2018 at 09:14:05PM +0200, Willy Tarreau wrote:
>The dependency chain however matters less because once you start fighting
>with a small patch set for 1 hour you can spend an extra minute testing
>several combinations or figuring the dependencies in mainline.
https://git.kernel.org/
On Thu, May 03, 2018 at 11:55:29AM -0700, Greg KH wrote:
> Don't care about me for stuff like this. Fix it correctly and I'll
> worry about any dependancy issues later :)
For me the real value of the Fixes header is to let the person doing
the backport know if they must search when the patch look
On Thu, May 03, 2018 at 07:20:39PM +0100, Al Viro wrote:
>On Thu, May 03, 2018 at 05:34:24PM +, Sasha Levin wrote:
>
>> >Moreover, what the hell do you suggest in situation when
>> >* foofs_barf() is b0rken in quite a few ways. There's an
>> >easily triggerable memory corruptor that can be
On Thu, May 03, 2018 at 06:12:36PM +, Sasha Levin wrote:
> I'm also not trying to argue whether 7% is high or low, only that it's 3
> times as many bugs per line of code than what we get from the merge
> window.
Yes but seen differently that's 14 times less bugs than the ones properly
fixed by
On Thu, May 03, 2018 at 02:08:51PM +0300, Jani Nikula wrote:
> On Tue, 01 May 2018, "Theodore Y. Ts'o" wrote:
> > Post -rc3 or -rc4, in my opinion bug fixes should wait until the next
> > merge window before they get merged at all.
>
> What are -rc5 and later for then if not bug fixes? Baffled.
On Thu, May 03, 2018 at 07:20:39PM +0100, Al Viro wrote:
> On Thu, May 03, 2018 at 05:34:24PM +, Sasha Levin wrote:
>
> > >Moreover, what the hell do you suggest in situation when
> > > * foofs_barf() is b0rken in quite a few ways. There's an
> > >easily triggerable memory corruptor that ca
On Thu, May 03, 2018 at 06:12:36PM +, Sasha Levin via Ksummit-discuss wrote:
>
> For example, how about extending the release cycle until the amount of
> fixes for regressions introduced in the current merge window drops under
> a certain thershold? (so go to -rc20 if we need to).
>
Reminds m
On Thu, May 03, 2018 at 05:34:24PM +, Sasha Levin wrote:
> >Moreover, what the hell do you suggest in situation when
> > * foofs_barf() is b0rken in quite a few ways. There's an
> >easily triggerable memory corruptor that can be fixed locally as well
> >as something else that needs a chan
On Thu, May 03, 2018 at 07:57:23PM +0200, Willy Tarreau wrote:
>On Thu, May 03, 2018 at 05:29:29PM +, Sasha Levin wrote:
>> I tried pulling all the fixes that went in 4.17 (so far) for bugs that
>> were introduced as fixes in the v4.16 cycle, I got this list:
>>
>> d65026c6c62e v4.16-rc7 5 6b1e
On Thu, 2018-05-03 at 15:43 +, Sasha Levin via Ksummit-discuss
wrote:
> On Thu, May 03, 2018 at 08:27:48AM -0700, James Bottomley wrote:
[...]
> > It's also a sad fact that a lot of things which look like obvious
> > fixes actually turn out not to be so with later testing. This is
> > why the
On Thu, May 03, 2018 at 05:29:29PM +, Sasha Levin wrote:
> I tried pulling all the fixes that went in 4.17 (so far) for bugs that
> were introduced as fixes in the v4.16 cycle, I got this list:
>
> d65026c6c62e v4.16-rc7 5 6b1e6cc7855b v4.7 d14d2b78090c
> 63489f8e8211 v4.16-rc6 13 045c7a3f53
On Thu, May 03, 2018 at 10:17:57AM -0700, Randy Dunlap wrote:
>On 05/03/2018 08:43 AM, Sasha Levin wrote:
>> On Thu, May 03, 2018 at 08:27:48AM -0700, James Bottomley wrote:
>>> On Thu, 2018-05-03 at 15:06 +, Sasha Levin via Ksummit-discuss
>>> wrote:
On Thu, May 03, 2018 at 04:48:50PM +02
On Thu, May 03, 2018 at 05:54:46PM +0100, Al Viro wrote:
>On Thu, May 03, 2018 at 02:46:14PM +, Sasha Levin via Ksummit-discuss
>wrote:
>
>> Fixes in -rc cycles:
>> rc1 68
>> rc2 147
>> rc3 88
>> rc4 121
>> rc5 40
>> rc6 193
>> rc7 98
>>
>> Average days in -next, for a fix, per -rc cycle:
>> r
On Thu, May 03, 2018 at 06:35:16PM +0200, Willy Tarreau wrote:
>On Thu, May 03, 2018 at 04:14:57PM +, Sasha Levin wrote:
>> I tried looking at a few commits that came in on -rc7, and I see quite a
>> few cases where a commit was merged to Linus' tree in about 24 hours
>> after it was authored.
On Thu, May 03, 2018 at 04:02:12PM +, Sasha Levin wrote:
> >You are misquoting me. I am saying that it would be a bad idea to hold up
> >bug fixes after -rc4, which is quite different to saying that patches
> >don't make it into stable releases fast enough. I am perfectly happy to
> >wait a wee
On Thu, May 03, 2018 at 02:46:14PM +, Sasha Levin via Ksummit-discuss wrote:
> Fixes in -rc cycles:
> rc1 68
> rc2 147
> rc3 88
> rc4 121
> rc5 40
> rc6 193
> rc7 98
>
> Average days in -next, for a fix, per -rc cycle:
> rc1 27.25
> rc2 21.4286
> rc3 22.5114
> rc4 18.281
> rc5 14.65
> rc6 12.
On Thu, May 3, 2018 at 11:02 AM, Sasha Levin
wrote:
> On Thu, May 03, 2018 at 08:49:11AM -0700, Guenter Roeck wrote:
>>On Thu, May 03, 2018 at 02:55:36PM +, Sasha Levin wrote:
>>> On Wed, May 02, 2018 at 05:38:32PM -0700, Guenter Roeck wrote:
>>> >On 05/02/2018 05:06 PM, Theodore Y. Ts'o wrote
On Thu, May 03, 2018 at 04:14:57PM +, Sasha Levin wrote:
> I tried looking at a few commits that came in on -rc7, and I see quite a
> few cases where a commit was merged to Linus' tree in about 24 hours
> after it was authored. Or maintainers who just wrote it, pushed it in,
> and shipped in to
On Thu, May 03, 2018 at 06:00:46PM +0200, Willy Tarreau wrote:
>On Thu, May 03, 2018 at 03:01:08PM +, Sasha Levin wrote:
>> On Thu, May 03, 2018 at 04:52:05PM +0200, Willy Tarreau wrote:
>> >I wouldn't be much surprised if you'd find that among those not introduced
>> >in the current merge wind
On Thu, May 03, 2018 at 08:49:11AM -0700, Guenter Roeck wrote:
>On Thu, May 03, 2018 at 02:55:36PM +, Sasha Levin wrote:
>> On Wed, May 02, 2018 at 05:38:32PM -0700, Guenter Roeck wrote:
>> >On 05/02/2018 05:06 PM, Theodore Y. Ts'o wrote:
>> >>On Wed, May 02, 2018 at 10:41:56PM +0200, Geert Uyt
On Thu, May 03, 2018 at 03:01:08PM +, Sasha Levin wrote:
> On Thu, May 03, 2018 at 04:52:05PM +0200, Willy Tarreau wrote:
> >I wouldn't be much surprised if you'd find that among those not introduced
> >in the current merge window, many were introduced in the previous release.
>
> Interesting.
1 - 100 of 123 matches
Mail list logo
