On Aug 21 Steven Rostedt wrote:
> I guess the other question to ask is, how long does it take for a
> problem to appear after hitting mainline? If a problem is found in -rc4
> before -rc5 comes out, then this would be sufficient. But if the
> problem from -rc4 isn't found till -rc6 then that tells
On Wed, Aug 21, 2013 at 10:54 PM, Tony Luck wrote:
> Running daily git snapshots can be "exciting" during the merge window. But
> I rarely see problems running a random build after -rc1. If you are still
Indeed.
> running that ancient 3.11-rc6 released on Sunday - then you are missing out
> on
On Wed, Aug 21, 2013 at 01:54:01PM -0700, Tony Luck wrote:
> On Wed, Aug 21, 2013 at 1:00 PM, Borislav Petkov wrote:
> > We don't want to run daily snapshots of your tree though, right? Only
> > -rcs because the daily states are kinda arbitrary and they can be broken
> > in various ways. Or are we
On Wed, 21 Aug 2013 11:36:05 -0700 Linus Torvalds
wrote:
>
> On Wed, Aug 21, 2013 at 11:20 AM, Stephen Warren
> wrote:
> > On 08/20/2013 04:40 PM, Greg KH wrote:
> >
> > Presumably the idea is that much useful testing only happens on -rc
> > kernels rather than linux-next or arbitrary points in
On Wed, Aug 21, 2013 at 01:16:00PM -0700, Greg KH wrote:
> And I pushed back on that. Which specific stable patch should _not_
> have been included?
Well, here's one for example:
https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=f0a56c480196a98479760862468cc95879df3de0
http://bu
On Wed, Aug 21, 2013 at 1:00 PM, Borislav Petkov wrote:
> We don't want to run daily snapshots of your tree though, right? Only
> -rcs because the daily states are kinda arbitrary and they can be broken
> in various ways. Or are we at a point in time where we can amend that
> rule?
If *nobody* ru
On Wed, Aug 21, 2013 at 10:07:03PM +0200, Borislav Petkov wrote:
> On Wed, Aug 21, 2013 at 01:58:16PM -0400, Steven Rostedt wrote:
> > The point I'm making, we should be more reluctant in pulling patches
> > into stable as quick as we are. A patch ideally should simmer in
> > linux-next for a bit,
On Wed, Aug 21, 2013 at 01:58:16PM -0400, Steven Rostedt wrote:
> The point I'm making, we should be more reluctant in pulling patches
> into stable as quick as we are. A patch ideally should simmer in
> linux-next for a bit, then go into mainline.
Oh, and it is really debatable if the sheer volum
On Wed, Aug 21, 2013 at 11:36:05AM -0700, Linus Torvalds wrote:
> Will it catch all cases? Hell no. We don't have *that* many people who
> run git kernels, and even people who do don't tend to update daily
> anyway.
We don't want to run daily snapshots of your tree though, right? Only
-rcs because
On Wed, Aug 21, 2013 at 11:20 AM, Stephen Warren wrote:
> On 08/20/2013 04:40 PM, Greg KH wrote:
>
> Presumably the idea is that much useful testing only happens on -rc
> kernels rather than linux-next or arbitrary points in Linus' tree.
Linux-next gets little to no testing outside of compiles.
On 08/20/2013 04:40 PM, Greg KH wrote:
> Hi all,
>
> Given that I had to just revert a patch in the recent stable releases
> that didn't get enough time to "bake" in Linus's tree (or in -next), I
> figured it was worth discussing some possible changes with how "fast" I
> pick up patches for stable
On Tue, Aug 20, 2013 at 09:03:12PM -0400, Josh Boyer wrote:
> Suspend/Resume is broken on a variety of Thinkpad T400 and T500
> machines in 3.10. This was true with 3.10.0 afaik. Current thinking
> is that it's related to the Intel mei/mei_me driver(s). Blacklisting
> those seems to fix things f
On Wed, 21 Aug 2013 19:23:27 +0200
Jochen Striepe wrote:
> ... people are very different. Many just update here and then, but
> there are those who do update on most stable releases. Those are the
> ones you get feedback and testing from, and I think you should encourage
> them to update as soon
Hello,
just speaking as a user, not a developer.
On Wed, Aug 21, 2013 at 09:37:13AM -0400, Steven Rostedt wrote:
> First I want to say that I 100% support the idea of waiting at least one
> -rc. Maybe even two.
I think so, too. But ...
> Really, most fixes are for regressions.
[...]
> I
On Wed, Aug 21, 2013 at 03:48:52PM +0200, Borislav Petkov wrote:
> On Tue, Aug 20, 2013 at 03:40:32PM -0700, Greg KH wrote:
> > - I will wait for a -rc to come out with the patch in it before putting
> > it into a stable release, unless:
>
> Question: what's the exact reasoning of that delay? To
On Wed, 21 Aug 2013 16:17:25 +0200
Willy Tarreau wrote:
> This is also what I suspected though I have no data to confirm or deny that.
> If this happens to be the case, maybe then there should be some barrier such
> as :
> - everything merged at -rc4 or before gets backported after the next -rc
On Wed, Aug 21, 2013 at 09:42:48AM -0400, Steven Rostedt wrote:
> Personally, I still let my stable patches that go into later -rc sit
> in linux-next for a few days before pushing them to mainline. I may even
> wait for the next -rc to push it just to make sure the patch wont cause
> more issues.
On Tue, Aug 20, 2013 at 03:40:32PM -0700, Greg KH wrote:
> - I will wait for a -rc to come out with the patch in it before putting
> it into a stable release, unless:
Question: what's the exact reasoning of that delay? To get more people
who install -rc kernels to smoke-test patches tagged for s
On Tue, Aug 20, 2013 at 08:41:23PM -0400, Josh Boyer wrote:
>
> Let me phrase this as a question instead. Is there something we can
> do to help catch the patches that get sucked into stable during the
> merge window and then wind up causing issues and reverted/fixed after
> things settle down in
First I want to say that I 100% support the idea of waiting at least one
-rc. Maybe even two.
On Wed, Aug 21, 2013 at 07:38:36AM +0200, Willy Tarreau wrote:
> > Cc: stable # after -rc5 is out
> > or
> > Cc: stable # wait a -rc cycle
> > or
> > Cc: stable # wait a few weeks to bake
On Tue, Aug 20, 2013 at 05:49:24PM -0700, Greg KH wrote:
> On Tue, Aug 20, 2013 at 08:41:23PM -0400, Josh Boyer wrote:
> > On Tue, Aug 20, 2013 at 7:57 PM, Greg KH wrote:
> > >> I like this overall. The only thing I might change is "wait for -rc2"
> > >> for patches tagged with CC: stable that go
On Tue, Aug 20, 2013 at 04:12:32PM -0700, Greg KH wrote:
> On Wed, Aug 21, 2013 at 12:58:15AM +0200, Willy Tarreau wrote:
> > Hi Greg,
> >
> > On Tue, Aug 20, 2013 at 03:40:32PM -0700, Greg KH wrote:
> > > Hi all,
> > >
> > > Given that I had to just revert a patch in the recent stable releases
>
On Tue, Aug 20, 2013 at 09:03:12PM -0400, Josh Boyer wrote:
[ ... ]
>
> Suspend/Resume is broken on a variety of Thinkpad T400 and T500
> machines in 3.10. This was true with 3.10.0 afaik. Current thinking
> is that it's related to the Intel mei/mei_me driver(s). Blacklisting
Reminds me ... I
On Tue, Aug 20, 2013 at 8:49 PM, Greg KH wrote:
> On Tue, Aug 20, 2013 at 08:41:23PM -0400, Josh Boyer wrote:
>> On Tue, Aug 20, 2013 at 7:57 PM, Greg KH wrote:
>> >> I like this overall. The only thing I might change is "wait for -rc2"
>> >> for patches tagged with CC: stable that go in during
On Tue, Aug 20, 2013 at 08:41:23PM -0400, Josh Boyer wrote:
> On Tue, Aug 20, 2013 at 7:57 PM, Greg KH wrote:
> >> I like this overall. The only thing I might change is "wait for -rc2"
> >> for patches tagged with CC: stable that go in during the merge window.
> >> It seems those are the ones th
On Tue, Aug 20, 2013 at 7:57 PM, Greg KH wrote:
> On Tue, Aug 20, 2013 at 07:40:49PM -0400, Josh Boyer wrote:
>> On Tue, Aug 20, 2013 at 6:40 PM, Greg KH wrote:
>> > Hi all,
>> >
>> > Given that I had to just revert a patch in the recent stable releases
>> > that didn't get enough time to "bake"
On Tue, Aug 20, 2013 at 05:11:11PM -0700, Guenter Roeck wrote:
> On Tue, Aug 20, 2013 at 04:17:43PM -0700, Greg KH wrote:
> > On Tue, Aug 20, 2013 at 04:11:17PM -0700, Guenter Roeck wrote:
> > > It would be even better if you could find the time to push -rc releases
> > > into the stable repository
On Tue, Aug 20, 2013 at 04:17:43PM -0700, Greg KH wrote:
> On Tue, Aug 20, 2013 at 04:11:17PM -0700, Guenter Roeck wrote:
> > It would be even better if you could find the time to push -rc releases
> > into the stable repository before you accept patches into a stable branch.
>
> What do you mean
On Tue, Aug 20, 2013 at 04:12:32PM -0700, Greg KH wrote:
> On Wed, Aug 21, 2013 at 12:58:15AM +0200, Willy Tarreau wrote:
> > Hi Greg,
> >
> > On Tue, Aug 20, 2013 at 03:40:32PM -0700, Greg KH wrote:
> > > Hi all,
> > >
> > > Given that I had to just revert a patch in the recent stable releases
>
On Tue, Aug 20, 2013 at 07:40:49PM -0400, Josh Boyer wrote:
> On Tue, Aug 20, 2013 at 6:40 PM, Greg KH wrote:
> > Hi all,
> >
> > Given that I had to just revert a patch in the recent stable releases
> > that didn't get enough time to "bake" in Linus's tree (or in -next), I
> > figured it was wort
On Tue, Aug 20, 2013 at 6:40 PM, Greg KH wrote:
> Hi all,
>
> Given that I had to just revert a patch in the recent stable releases
> that didn't get enough time to "bake" in Linus's tree (or in -next), I
> figured it was worth discussing some possible changes with how "fast" I
> pick up patches f
On Tue, Aug 20, 2013 at 04:11:17PM -0700, Guenter Roeck wrote:
> It would be even better if you could find the time to push -rc releases
> into the stable repository before you accept patches into a stable branch.
What do you mean by this?
The git tree? I could do that, but when I have to drop a
On Wed, Aug 21, 2013 at 12:58:15AM +0200, Willy Tarreau wrote:
> Hi Greg,
>
> On Tue, Aug 20, 2013 at 03:40:32PM -0700, Greg KH wrote:
> > Hi all,
> >
> > Given that I had to just revert a patch in the recent stable releases
> > that didn't get enough time to "bake" in Linus's tree (or in -next),
On Tue, Aug 20, 2013 at 03:40:32PM -0700, Greg KH wrote:
> Hi all,
>
> Given that I had to just revert a patch in the recent stable releases
> that didn't get enough time to "bake" in Linus's tree (or in -next), I
> figured it was worth discussing some possible changes with how "fast" I
> pick up
On Tue, Aug 20, 2013 at 04:04:00PM -0700, Nicholas A. Bellinger wrote:
> On Tue, 2013-08-20 at 15:40 -0700, Greg KH wrote:
> > Hi all,
> >
> > Given that I had to just revert a patch in the recent stable releases
> > that didn't get enough time to "bake" in Linus's tree (or in -next), I
> > figure
Hi Greg,
On Tue, Aug 20, 2013 at 03:40:32PM -0700, Greg KH wrote:
> Hi all,
>
> Given that I had to just revert a patch in the recent stable releases
> that didn't get enough time to "bake" in Linus's tree (or in -next), I
> figured it was worth discussing some possible changes with how "fast" I
On Tue, 2013-08-20 at 15:40 -0700, Greg KH wrote:
> Hi all,
>
> Given that I had to just revert a patch in the recent stable releases
> that didn't get enough time to "bake" in Linus's tree (or in -next), I
> figured it was worth discussing some possible changes with how "fast" I
> pick up patches
Hi all,
Given that I had to just revert a patch in the recent stable releases
that didn't get enough time to "bake" in Linus's tree (or in -next), I
figured it was worth discussing some possible changes with how "fast" I
pick up patches for stable releases.
So, how about this proposal:
- I will
38 matches
Mail list logo
