* Linus Torvalds wrote:
> [...]
>
> Anyway, the point I'm making is that Q is limited and often even
> actively misleading ("Hey, I have three tested-by's, so it must be
> fine"), and we might actually want to have a new class of "non-critical
> patch that might be worth backporting to
* Linus Torvalds torva...@linux-foundation.org wrote:
[...]
Anyway, the point I'm making is that QA is limited and often even
actively misleading (Hey, I have three tested-by's, so it must be
fine), and we might actually want to have a new class of non-critical
patch that might be
On 2013/7/17 4:10, Willy Tarreau wrote:
> On Tue, Jul 16, 2013 at 03:43:09PM -0400, Steven Rostedt wrote:
>> On Tue, 2013-07-16 at 12:11 -0700, Greg Kroah-Hartman wrote:
>>
>>> People mark stable patches that way already today with a:
>>> Cc: stable # delay for 3.12-rc4
>>> or some such
On 2013/7/17 4:10, Willy Tarreau wrote:
On Tue, Jul 16, 2013 at 03:43:09PM -0400, Steven Rostedt wrote:
On Tue, 2013-07-16 at 12:11 -0700, Greg Kroah-Hartman wrote:
People mark stable patches that way already today with a:
Cc: stable sta...@vger.kernel.org # delay for 3.12-rc4
or some
On Tue, 2013-07-16 at 22:10 +0200, Willy Tarreau wrote:
> On Tue, Jul 16, 2013 at 03:43:09PM -0400, Steven Rostedt wrote:
> > On Tue, 2013-07-16 at 12:11 -0700, Greg Kroah-Hartman wrote:
> >
> > > People mark stable patches that way already today with a:
> > > Cc: stable # delay for 3.12-rc4
>
On Tue, 16 Jul 2013, H. Peter Anvin wrote:
On 07/16/2013 12:19 AM, David Lang wrote:
On Fri, 12 Jul 2013, Willy Tarreau wrote:
And maybe in the end, having 1/10 patch cause a regression is not *that*
dramatic, and probably less than not fixing the 9 other bugs. In one case
we rely on -stable
On Tue, Jul 16, 2013 at 03:43:09PM -0400, Steven Rostedt wrote:
> On Tue, 2013-07-16 at 12:11 -0700, Greg Kroah-Hartman wrote:
>
> > People mark stable patches that way already today with a:
> > Cc: stable # delay for 3.12-rc4
> > or some such wording. I take those and don't apply them
On Tue, 2013-07-16 at 12:11 -0700, Greg Kroah-Hartman wrote:
> People mark stable patches that way already today with a:
> Cc: stable # delay for 3.12-rc4
> or some such wording. I take those and don't apply them until the noted
> release happens, so you can do this if needed.
I guess
At Tue, 16 Jul 2013 09:42:34 -0700 (PDT),
David Lang wrote:
>
> On Tue, 16 Jul 2013, Takashi Iwai wrote:
>
> > At Tue, 16 Jul 2013 00:19:16 -0700 (PDT),
> > David Lang wrote:
> >>
> >> On Fri, 12 Jul 2013, Willy Tarreau wrote:
> >>
> >>> And maybe in the end, having 1/10 patch cause a regression
On Tue, Jul 16, 2013 at 02:41:24PM -0400, Steven Rostedt wrote:
> On Tue, 2013-07-16 at 11:29 -0700, Linus Torvalds wrote:
>
> > Anyway, the point I'm making is that Q is limited and often even
> > actively misleading ("Hey, I have three tested-by's, so it must be
> > fine"), and we might
On Tue, Jul 16, 2013 at 11:29:15AM -0700, Linus Torvalds wrote:
> There have been tons of obvious patches that turned out to simply be
> wrong - often for very non-obvious reasons. Even when they are small.
> And the problems seldom get caught in early testing, often exactly
> because of this
On Tue, 2013-07-16 at 11:29 -0700, Linus Torvalds wrote:
> Anyway, the point I'm making is that Q is limited and often even
> actively misleading ("Hey, I have three tested-by's, so it must be
> fine"), and we might actually want to have a new class of
> "non-critical patch that might be worth
On 07/16/2013 12:19 AM, David Lang wrote:
> On Fri, 12 Jul 2013, Willy Tarreau wrote:
>
>> And maybe in the end, having 1/10 patch cause a regression is not *that*
>> dramatic, and probably less than not fixing the 9 other bugs. In one case
>> we rely on -stable to merge the 10 fixes, and on the
Hi Takashi,
On Tue, Jul 16, 2013 at 06:40:39PM +0200, Takashi Iwai wrote:
> IMO, one of the reasons is the nature of stable-release: the stable
> tree is released soon after reviews of patches, so no actual
> regression tests can be done before the release.
>
> For finding a regression, patch
On Tue, Jul 16, 2013 at 10:58 AM, Luck, Tony wrote:
>
> Linux testing is (realistically) done by inflicting changes on gradually wider
> sets of end users.
However, one thing that people should keep in mind that the testing is
often self-selecting.
This is particularly true for "obvious fixes".
>> Maybe some QA period before the release might help, but who would
>> care? (Especially under the situation where everybody has own x.y
>> stable tree?)
>
> Hopefully people tracking the upstream stable trees would be throwing
> any pre-release stuff into their QA processes before it was
On Tue, Jul 16, 2013 at 06:40:39PM +0200, Takashi Iwai wrote:
> Maybe some QA period before the release might help, but who would
> care? (Especially under the situation where everybody has own x.y
> stable tree?)
Hopefully people tracking the upstream stable trees would be throwing
any
On Tue, 16 Jul 2013, Takashi Iwai wrote:
At Tue, 16 Jul 2013 00:19:16 -0700 (PDT),
David Lang wrote:
On Fri, 12 Jul 2013, Willy Tarreau wrote:
And maybe in the end, having 1/10 patch cause a regression is not *that*
dramatic, and probably less than not fixing the 9 other bugs. In one case
At Tue, 16 Jul 2013 00:19:16 -0700 (PDT),
David Lang wrote:
>
> On Fri, 12 Jul 2013, Willy Tarreau wrote:
>
> > And maybe in the end, having 1/10 patch cause a regression is not *that*
> > dramatic, and probably less than not fixing the 9 other bugs. In one case
> > we rely on -stable to merge
At Tue, 16 Jul 2013 00:19:16 -0700 (PDT),
David Lang wrote:
On Fri, 12 Jul 2013, Willy Tarreau wrote:
And maybe in the end, having 1/10 patch cause a regression is not *that*
dramatic, and probably less than not fixing the 9 other bugs. In one case
we rely on -stable to merge the 10
On Tue, 16 Jul 2013, Takashi Iwai wrote:
At Tue, 16 Jul 2013 00:19:16 -0700 (PDT),
David Lang wrote:
On Fri, 12 Jul 2013, Willy Tarreau wrote:
And maybe in the end, having 1/10 patch cause a regression is not *that*
dramatic, and probably less than not fixing the 9 other bugs. In one case
On Tue, Jul 16, 2013 at 06:40:39PM +0200, Takashi Iwai wrote:
Maybe some QA period before the release might help, but who would
care? (Especially under the situation where everybody has own x.y
stable tree?)
Hopefully people tracking the upstream stable trees would be throwing
any
Maybe some QA period before the release might help, but who would
care? (Especially under the situation where everybody has own x.y
stable tree?)
Hopefully people tracking the upstream stable trees would be throwing
any pre-release stuff into their QA processes before it was officially
On Tue, Jul 16, 2013 at 10:58 AM, Luck, Tony tony.l...@intel.com wrote:
Linux testing is (realistically) done by inflicting changes on gradually wider
sets of end users.
However, one thing that people should keep in mind that the testing is
often self-selecting.
This is particularly true for
Hi Takashi,
On Tue, Jul 16, 2013 at 06:40:39PM +0200, Takashi Iwai wrote:
IMO, one of the reasons is the nature of stable-release: the stable
tree is released soon after reviews of patches, so no actual
regression tests can be done before the release.
For finding a regression, patch reviews
On 07/16/2013 12:19 AM, David Lang wrote:
On Fri, 12 Jul 2013, Willy Tarreau wrote:
And maybe in the end, having 1/10 patch cause a regression is not *that*
dramatic, and probably less than not fixing the 9 other bugs. In one case
we rely on -stable to merge the 10 fixes, and on the other
On Tue, 2013-07-16 at 11:29 -0700, Linus Torvalds wrote:
Anyway, the point I'm making is that QA is limited and often even
actively misleading (Hey, I have three tested-by's, so it must be
fine), and we might actually want to have a new class of
non-critical patch that might be worth
On Tue, Jul 16, 2013 at 11:29:15AM -0700, Linus Torvalds wrote:
There have been tons of obvious patches that turned out to simply be
wrong - often for very non-obvious reasons. Even when they are small.
And the problems seldom get caught in early testing, often exactly
because of this
On Tue, Jul 16, 2013 at 02:41:24PM -0400, Steven Rostedt wrote:
On Tue, 2013-07-16 at 11:29 -0700, Linus Torvalds wrote:
Anyway, the point I'm making is that QA is limited and often even
actively misleading (Hey, I have three tested-by's, so it must be
fine), and we might actually want to
At Tue, 16 Jul 2013 09:42:34 -0700 (PDT),
David Lang wrote:
On Tue, 16 Jul 2013, Takashi Iwai wrote:
At Tue, 16 Jul 2013 00:19:16 -0700 (PDT),
David Lang wrote:
On Fri, 12 Jul 2013, Willy Tarreau wrote:
And maybe in the end, having 1/10 patch cause a regression is not *that*
On Tue, 2013-07-16 at 12:11 -0700, Greg Kroah-Hartman wrote:
People mark stable patches that way already today with a:
Cc: stable sta...@vger.kernel.org # delay for 3.12-rc4
or some such wording. I take those and don't apply them until the noted
release happens, so you can do this if
On Tue, Jul 16, 2013 at 03:43:09PM -0400, Steven Rostedt wrote:
On Tue, 2013-07-16 at 12:11 -0700, Greg Kroah-Hartman wrote:
People mark stable patches that way already today with a:
Cc: stable sta...@vger.kernel.org # delay for 3.12-rc4
or some such wording. I take those and don't
On Tue, 16 Jul 2013, H. Peter Anvin wrote:
On 07/16/2013 12:19 AM, David Lang wrote:
On Fri, 12 Jul 2013, Willy Tarreau wrote:
And maybe in the end, having 1/10 patch cause a regression is not *that*
dramatic, and probably less than not fixing the 9 other bugs. In one case
we rely on -stable
On Tue, 2013-07-16 at 22:10 +0200, Willy Tarreau wrote:
On Tue, Jul 16, 2013 at 03:43:09PM -0400, Steven Rostedt wrote:
On Tue, 2013-07-16 at 12:11 -0700, Greg Kroah-Hartman wrote:
People mark stable patches that way already today with a:
Cc: stable sta...@vger.kernel.org # delay for
On Fri, Jul 12, 2013 at 8:14 PM, Steven Rostedt wrote:
> On Fri, 2013-07-12 at 10:59 -0700, Linus Torvalds wrote:
>> On Fri, Jul 12, 2013 at 10:50 AM, Steven Rostedt wrote:
>> >
>> > Perhaps just make a separate stable branch, where you cherry-pick the
>> > specific patch using the -x option.
On Friday, July 12, 2013 06:32:11 PM Greg Kroah-Hartman wrote:
> On Sat, Jul 13, 2013 at 02:24:07AM +0200, Rafael J. Wysocki wrote:
> > On Thursday, July 11, 2013 08:34:30 PM Greg Kroah-Hartman wrote:
> > > On Thu, Jul 11, 2013 at 10:57:46PM -0400, John W. Linville wrote:
> > > > On Thu, Jul 11,
* Linus Torvalds wrote:
> On Fri, Jul 12, 2013 at 11:28 AM, H. Peter Anvin wrote:
> >
> > OK, just read up some more on git notes, and *both* the assumptions I
> > had made about git notes were fundamentally wrong. Not sure how well
> > they would scale, though, but stuffing metadata like
* Linus Torvalds torva...@linux-foundation.org wrote:
On Fri, Jul 12, 2013 at 11:28 AM, H. Peter Anvin h...@zytor.com wrote:
OK, just read up some more on git notes, and *both* the assumptions I
had made about git notes were fundamentally wrong. Not sure how well
they would scale,
On Friday, July 12, 2013 06:32:11 PM Greg Kroah-Hartman wrote:
On Sat, Jul 13, 2013 at 02:24:07AM +0200, Rafael J. Wysocki wrote:
On Thursday, July 11, 2013 08:34:30 PM Greg Kroah-Hartman wrote:
On Thu, Jul 11, 2013 at 10:57:46PM -0400, John W. Linville wrote:
On Thu, Jul 11, 2013 at
On Fri, Jul 12, 2013 at 8:14 PM, Steven Rostedt rost...@goodmis.org wrote:
On Fri, 2013-07-12 at 10:59 -0700, Linus Torvalds wrote:
On Fri, Jul 12, 2013 at 10:50 AM, Steven Rostedt rost...@goodmis.org wrote:
Perhaps just make a separate stable branch, where you cherry-pick the
specific
On Sat, Jul 13, 2013 at 02:24:07AM +0200, Rafael J. Wysocki wrote:
> On Thursday, July 11, 2013 08:34:30 PM Greg Kroah-Hartman wrote:
> > On Thu, Jul 11, 2013 at 10:57:46PM -0400, John W. Linville wrote:
> > > On Thu, Jul 11, 2013 at 08:50:23PM -0400, Theodore Ts'o wrote:
> > >
> > > > In any
On Thursday, July 11, 2013 08:34:30 PM Greg Kroah-Hartman wrote:
> On Thu, Jul 11, 2013 at 10:57:46PM -0400, John W. Linville wrote:
> > On Thu, Jul 11, 2013 at 08:50:23PM -0400, Theodore Ts'o wrote:
> >
> > > In any case, I've been very conservative in _not_ pushing bug fixes to
> > > Linus
On 07/12/2013 01:33 PM, Greg Kroah-Hartman wrote:
>
> Is it _really_ all that hard to remember what to mark for stable
> inclusion? If you figure it out after you have committed the patch,
> then just put a copy of it somewhere to remind yourself. That seems to
> be what both David and I do
On 07/12/2013 12:53 PM, Steven Rostedt wrote:
> On Fri, 2013-07-12 at 12:44 -0700, Linus Torvalds wrote:
>
>> They can be useful for "local" notes (they can be very powerful for
>> certain workflows), but they won't be pulled and pushed by me.
>
> Perhaps notes can be used as that reminder to
On Fri, 2013-07-12 at 13:33 -0700, Greg Kroah-Hartman wrote:
> That's what mailboxes are for, use a script of 'git send-email' to send
> it to yourself and save it somewhere. Use patchwork. Use a text file
> to remind yourself. Use quilt, like Andrew does, he has a great track
> record of
On Fri, Jul 12, 2013 at 03:53:17PM -0400, Steven Rostedt wrote:
> On Fri, 2013-07-12 at 12:44 -0700, Linus Torvalds wrote:
>
> > They can be useful for "local" notes (they can be very powerful for
> > certain workflows), but they won't be pulled and pushed by me.
>
> Perhaps notes can be used as
On Fri, Jul 12, 2013 at 1:53 PM, Steven Rostedt wrote:
> On Fri, 2013-07-12 at 12:44 -0700, Linus Torvalds wrote:
>
>> They can be useful for "local" notes (they can be very powerful for
>> certain workflows), but they won't be pulled and pushed by me.
>
> Perhaps notes can be used as that
On Fri, 2013-07-12 at 12:44 -0700, Linus Torvalds wrote:
> They can be useful for "local" notes (they can be very powerful for
> certain workflows), but they won't be pulled and pushed by me.
Perhaps notes can be used as that reminder to send to stable. Tag a
commit with a note, and have some
On Fri, Jul 12, 2013 at 11:28 AM, H. Peter Anvin wrote:
>
> OK, just read up some more on git notes, and *both* the assumptions I
> had made about git notes were fundamentally wrong. Not sure how well
> they would scale, though, but stuffing metadata like additional
> Acked-by:, Tested-by: and
On 07/12/2013 11:16 AM, H. Peter Anvin wrote:
>
> This relates to the "a posteori metadata" problem with git. In theory I
> think git notes should handle those, but I have to admit that git notes
> somewhat creep me out because there doesn't seem to be any version
> control on them, and as far
On 07/12/2013 10:57 AM, Theodore Ts'o wrote:
> On Fri, Jul 12, 2013 at 10:28:36AM -0700, Greg Kroah-Hartman wrote:
>> On Fri, Jul 12, 2013 at 10:20:46AM -0700, H. Peter Anvin wrote:
>>> On the subject of the stable tree: could we get a standard format for
>>> requesting post-inclusion elevation of
On Fri, 2013-07-12 at 10:59 -0700, Linus Torvalds wrote:
> On Fri, Jul 12, 2013 at 10:50 AM, Steven Rostedt wrote:
> >
> > Perhaps just make a separate stable branch, where you cherry-pick the
> > specific patch using the -x option. Adds a "(cherry picked from
> > commit ...)". Then you could
On Fri, Jul 12, 2013 at 01:57:18PM -0400, Theodore Ts'o wrote:
> On Fri, Jul 12, 2013 at 10:28:36AM -0700, Greg Kroah-Hartman wrote:
> > On Fri, Jul 12, 2013 at 10:20:46AM -0700, H. Peter Anvin wrote:
> > > On the subject of the stable tree: could we get a standard format for
> > > requesting
On Fri, Jul 12, 2013 at 10:50 AM, Steven Rostedt wrote:
>
> Perhaps just make a separate stable branch, where you cherry-pick the
> specific patch using the -x option. Adds a "(cherry picked from
> commit ...)". Then you could have some filter that monitors Linus
> commits and when a commit
On Fri, Jul 12, 2013 at 10:28:36AM -0700, Greg Kroah-Hartman wrote:
> On Fri, Jul 12, 2013 at 10:20:46AM -0700, H. Peter Anvin wrote:
> > On the subject of the stable tree: could we get a standard format for
> > requesting post-inclusion elevation of patches to stable status? It
> > isn't all
On Fri, 2013-07-12 at 10:28 -0700, Greg Kroah-Hartman wrote:
> Yes, this requires you to remember to do this after it hits Linus's
> tree, so you could do like David does for networking, and keep a
> seperate tree to send to me specifically for stable patches. I think he
> uses patchwork, but I
On Fri, Jul 12, 2013 at 10:20:46AM -0700, H. Peter Anvin wrote:
> On the subject of the stable tree: could we get a standard format for
> requesting post-inclusion elevation of patches to stable status? It
> isn't all that unusual that the need for -stable is highlighted after a
> patch has been
On the subject of the stable tree: could we get a standard format for
requesting post-inclusion elevation of patches to stable status? It
isn't all that unusual that the need for -stable is highlighted after a
patch has been included in a maintainer's tree, and rebasing to add
stable metadata
On 07/11/2013 05:50 PM, Theodore Ts'o wrote:
>
> At least at one point in the past...
>
And at at least one *other* point in the past, Linus stated that
"holding back anything with a Cc: stable waiting for the merge window is
wrong". This would imply that the post-rc5-or-so policy and the
On Fri, Jul 12, 2013 at 5:46 AM, Jiri Kosina wrote:
> On Thu, 11 Jul 2013, Steven Rostedt wrote:
>
>> > Maybe the pendulum has swung too far in the direction of holding back
>> > changes and trying to avoid the risk of introducing regressions;
>> > perhaps this would be a good topic to discuss at
On Thu, 11 Jul 2013, Steven Rostedt wrote:
> > Maybe the pendulum has swung too far in the direction of holding back
> > changes and trying to avoid the risk of introducing regressions;
> > perhaps this would be a good topic to discuss at the Kernel Summit.
>
> Bah, I sent out a similar email
On Thu, 2013-07-11 at 20:34 -0700, Greg Kroah-Hartman wrote:
> On Thu, Jul 11, 2013 at 10:57:46PM -0400, John W. Linville wrote:
> > On Thu, Jul 11, 2013 at 08:50:23PM -0400, Theodore Ts'o wrote:
> >
> > > In any case, I've been very conservative in _not_ pushing bug fixes to
> > > Linus after
On Thu, 2013-07-11 at 20:34 -0700, Greg Kroah-Hartman wrote:
On Thu, Jul 11, 2013 at 10:57:46PM -0400, John W. Linville wrote:
On Thu, Jul 11, 2013 at 08:50:23PM -0400, Theodore Ts'o wrote:
In any case, I've been very conservative in _not_ pushing bug fixes to
Linus after -rc3 (unless
On Thu, 11 Jul 2013, Steven Rostedt wrote:
Maybe the pendulum has swung too far in the direction of holding back
changes and trying to avoid the risk of introducing regressions;
perhaps this would be a good topic to discuss at the Kernel Summit.
Bah, I sent out a similar email about
On Fri, Jul 12, 2013 at 5:46 AM, Jiri Kosina jkos...@suse.cz wrote:
On Thu, 11 Jul 2013, Steven Rostedt wrote:
Maybe the pendulum has swung too far in the direction of holding back
changes and trying to avoid the risk of introducing regressions;
perhaps this would be a good topic to
On 07/11/2013 05:50 PM, Theodore Ts'o wrote:
At least at one point in the past...
And at at least one *other* point in the past, Linus stated that
holding back anything with a Cc: stable waiting for the merge window is
wrong. This would imply that the post-rc5-or-so policy and the stable
On the subject of the stable tree: could we get a standard format for
requesting post-inclusion elevation of patches to stable status? It
isn't all that unusual that the need for -stable is highlighted after a
patch has been included in a maintainer's tree, and rebasing to add
stable metadata
On Fri, Jul 12, 2013 at 10:20:46AM -0700, H. Peter Anvin wrote:
On the subject of the stable tree: could we get a standard format for
requesting post-inclusion elevation of patches to stable status? It
isn't all that unusual that the need for -stable is highlighted after a
patch has been
On Fri, 2013-07-12 at 10:28 -0700, Greg Kroah-Hartman wrote:
Yes, this requires you to remember to do this after it hits Linus's
tree, so you could do like David does for networking, and keep a
seperate tree to send to me specifically for stable patches. I think he
uses patchwork, but I know
On Fri, Jul 12, 2013 at 10:28:36AM -0700, Greg Kroah-Hartman wrote:
On Fri, Jul 12, 2013 at 10:20:46AM -0700, H. Peter Anvin wrote:
On the subject of the stable tree: could we get a standard format for
requesting post-inclusion elevation of patches to stable status? It
isn't all that
On Fri, Jul 12, 2013 at 10:50 AM, Steven Rostedt rost...@goodmis.org wrote:
Perhaps just make a separate stable branch, where you cherry-pick the
specific patch using the -x option. Adds a (cherry picked from
commit ...). Then you could have some filter that monitors Linus
commits and when a
On Fri, Jul 12, 2013 at 01:57:18PM -0400, Theodore Ts'o wrote:
On Fri, Jul 12, 2013 at 10:28:36AM -0700, Greg Kroah-Hartman wrote:
On Fri, Jul 12, 2013 at 10:20:46AM -0700, H. Peter Anvin wrote:
On the subject of the stable tree: could we get a standard format for
requesting
On Fri, 2013-07-12 at 10:59 -0700, Linus Torvalds wrote:
On Fri, Jul 12, 2013 at 10:50 AM, Steven Rostedt rost...@goodmis.org wrote:
Perhaps just make a separate stable branch, where you cherry-pick the
specific patch using the -x option. Adds a (cherry picked from
commit ...). Then you
On 07/12/2013 10:57 AM, Theodore Ts'o wrote:
On Fri, Jul 12, 2013 at 10:28:36AM -0700, Greg Kroah-Hartman wrote:
On Fri, Jul 12, 2013 at 10:20:46AM -0700, H. Peter Anvin wrote:
On the subject of the stable tree: could we get a standard format for
requesting post-inclusion elevation of patches
On 07/12/2013 11:16 AM, H. Peter Anvin wrote:
This relates to the a posteori metadata problem with git. In theory I
think git notes should handle those, but I have to admit that git notes
somewhat creep me out because there doesn't seem to be any version
control on them, and as far as I can
On Fri, Jul 12, 2013 at 11:28 AM, H. Peter Anvin h...@zytor.com wrote:
OK, just read up some more on git notes, and *both* the assumptions I
had made about git notes were fundamentally wrong. Not sure how well
they would scale, though, but stuffing metadata like additional
Acked-by:,
On Fri, 2013-07-12 at 12:44 -0700, Linus Torvalds wrote:
They can be useful for local notes (they can be very powerful for
certain workflows), but they won't be pulled and pushed by me.
Perhaps notes can be used as that reminder to send to stable. Tag a
commit with a note, and have some
On Fri, Jul 12, 2013 at 1:53 PM, Steven Rostedt rost...@goodmis.org wrote:
On Fri, 2013-07-12 at 12:44 -0700, Linus Torvalds wrote:
They can be useful for local notes (they can be very powerful for
certain workflows), but they won't be pulled and pushed by me.
Perhaps notes can be used as
On Fri, Jul 12, 2013 at 03:53:17PM -0400, Steven Rostedt wrote:
On Fri, 2013-07-12 at 12:44 -0700, Linus Torvalds wrote:
They can be useful for local notes (they can be very powerful for
certain workflows), but they won't be pulled and pushed by me.
Perhaps notes can be used as that
On Fri, 2013-07-12 at 13:33 -0700, Greg Kroah-Hartman wrote:
That's what mailboxes are for, use a script of 'git send-email' to send
it to yourself and save it somewhere. Use patchwork. Use a text file
to remind yourself. Use quilt, like Andrew does, he has a great track
record of marking
On 07/12/2013 12:53 PM, Steven Rostedt wrote:
On Fri, 2013-07-12 at 12:44 -0700, Linus Torvalds wrote:
They can be useful for local notes (they can be very powerful for
certain workflows), but they won't be pulled and pushed by me.
Perhaps notes can be used as that reminder to send to
On 07/12/2013 01:33 PM, Greg Kroah-Hartman wrote:
Is it _really_ all that hard to remember what to mark for stable
inclusion? If you figure it out after you have committed the patch,
then just put a copy of it somewhere to remind yourself. That seems to
be what both David and I do with no
On Thursday, July 11, 2013 08:34:30 PM Greg Kroah-Hartman wrote:
On Thu, Jul 11, 2013 at 10:57:46PM -0400, John W. Linville wrote:
On Thu, Jul 11, 2013 at 08:50:23PM -0400, Theodore Ts'o wrote:
In any case, I've been very conservative in _not_ pushing bug fixes to
Linus after -rc3
On Sat, Jul 13, 2013 at 02:24:07AM +0200, Rafael J. Wysocki wrote:
On Thursday, July 11, 2013 08:34:30 PM Greg Kroah-Hartman wrote:
On Thu, Jul 11, 2013 at 10:57:46PM -0400, John W. Linville wrote:
On Thu, Jul 11, 2013 at 08:50:23PM -0400, Theodore Ts'o wrote:
In any case, I've been
On Thu, Jul 11, 2013 at 10:57:46PM -0400, John W. Linville wrote:
> On Thu, Jul 11, 2013 at 08:50:23PM -0400, Theodore Ts'o wrote:
>
> > In any case, I've been very conservative in _not_ pushing bug fixes to
> > Linus after -rc3 (unless they are fixing a regression or the bug fix
> > is
On Thu, Jul 11, 2013 at 08:50:23PM -0400, Theodore Ts'o wrote:
> In any case, I've been very conservative in _not_ pushing bug fixes to
> Linus after -rc3 (unless they are fixing a regression or the bug fix
> is super-serious); I'd much rather have them cook in the ext4 tree
> where they can get
On Thu, 2013-07-11 at 20:50 -0400, Theodore Ts'o wrote:
> Maybe the pendulum has swung too far in the direction of holding back
> changes and trying to avoid the risk of introducing regressions;
> perhaps this would be a good topic to discuss at the Kernel Summit.
Bah, I sent out a similar email
On Thu, 2013-07-11 at 20:50 -0400, Theodore Ts'o wrote:
> On Thu, Jul 11, 2013 at 03:01:17PM -0700, Greg Kroah-Hartman wrote:
> >
> > I'm sitting on top of over 170 more patches that have been marked for
> > the stable releases right now that are not included in this set of
> > releases.
On Thu, 2013-07-11 at 20:50 -0400, Theodore Ts'o wrote:
On Thu, Jul 11, 2013 at 03:01:17PM -0700, Greg Kroah-Hartman wrote:
rant
I'm sitting on top of over 170 more patches that have been marked for
the stable releases right now that are not included in this set of
releases. The
On Thu, 2013-07-11 at 20:50 -0400, Theodore Ts'o wrote:
Maybe the pendulum has swung too far in the direction of holding back
changes and trying to avoid the risk of introducing regressions;
perhaps this would be a good topic to discuss at the Kernel Summit.
Bah, I sent out a similar email
On Thu, Jul 11, 2013 at 08:50:23PM -0400, Theodore Ts'o wrote:
In any case, I've been very conservative in _not_ pushing bug fixes to
Linus after -rc3 (unless they are fixing a regression or the bug fix
is super-serious); I'd much rather have them cook in the ext4 tree
where they can get a
On Thu, Jul 11, 2013 at 10:57:46PM -0400, John W. Linville wrote:
On Thu, Jul 11, 2013 at 08:50:23PM -0400, Theodore Ts'o wrote:
In any case, I've been very conservative in _not_ pushing bug fixes to
Linus after -rc3 (unless they are fixing a regression or the bug fix
is super-serious);
92 matches
Mail list logo