I review what I can, but recently have often missed the 2 day review
period.
Review from the authors and maintainers is probably more valuable than
that from generalists on the stable list.
From point of subsystem developers view, the problem is there are too many
stable branches. I can't
On 2013/7/23 5:24, KOSAKI Motohiro wrote:
I review what I can, but recently have often missed the 2 day review
period.
Review from the authors and maintainers is probably more valuable than
that from generalists on the stable list.
From point of subsystem developers view, the problem is
On Mon, 2013-07-15 at 23:27 +0400, James Bottomley wrote:
Before the 3.10.1-stable review thread degenerated into a disagreement
about habits of politeness, there were some solid points being made
which, I think, bear consideration and which may now be lost.
The problem, as Jiří Kosina put
On Tue, 2013-07-23 at 02:40 +, Myklebust, Trond wrote:
On Mon, 2013-07-15 at 23:27 +0400, James Bottomley wrote:
The solution, to me, looks simple: Let's co-opt a process we already
know how to do: mailing list review and tree handling. So the proposal
is simple:
1. Drop the
On Mon, 2013-07-22 at 19:47 -0700, James Bottomley wrote:
On Tue, 2013-07-23 at 02:40 +, Myklebust, Trond wrote:
On Mon, 2013-07-15 at 23:27 +0400, James Bottomley wrote:
The solution, to me, looks simple: Let's co-opt a process we already
know how to do: mailing list review and tree
On 07/15/2013 04:09:53 PM, Joe Perches wrote:
On Mon, 2013-07-15 at 16:56 -0400, Steven Rostedt wrote:
It may not be efficient for maintainers, but as maintainers we
should
spend a bit more time on stable releases.
The MAINTAINERS file specifies a difference between a
section that's
On Sat, 2013-07-20 at 23:11 -0500, Rob Landley wrote:
On 07/15/2013 02:27:56 PM, James Bottomley wrote:
Before the 3.10.1-stable review thread degenerated into a
disagreement
about habits of politeness, there were some solid points being made
which, I think, bear consideration and which
John W. Linville linvi...@tuxdriver.com writes:
Is having a flood of fixes in x.y.1 any worse than having to got to an
-rc8 or an -rc9?
I think it's better to send less fixes to -rc8 or -rc9 and focus more on
testing. That way there should be less regressions in later stages of
-rc releases
On Tue, Jul 16, 2013 at 11:43:36AM +0400, James Bottomley wrote:
On Mon, 2013-07-15 at 23:20 -0700, Greg KH wrote:
I think the real stable issue that _everyone_ keeps ignoring, is my
original complaint, in that people are using the -rc1 merge window to
get fixes in they should have sent
On Mon, 2013-07-15 at 17:06 -0700, Greg KH wrote:
On Mon, Jul 15, 2013 at 06:01:39PM -0400, Steven Rostedt wrote:
On Mon, 2013-07-15 at 14:44 -0700, Greg KH wrote:
I don't like this at all, just for the simple reason that it will push
the majority of the work of stable kernel
On Tue, Jul 16, 2013 at 03:30:01AM +0100, Ben Hutchings wrote:
Anything that's being reviewed on the stable list is public. I know
this is an old argument, but if you point out a fix you *know* has a
security impact then you'll help general distribution maintainers and
users a lot more than
On Tue, Jul 16, 2013 at 10:10:31AM +0400, James Bottomley wrote:
On Mon, 2013-07-15 at 17:06 -0700, Greg KH wrote:
On Mon, Jul 15, 2013 at 06:01:39PM -0400, Steven Rostedt wrote:
On Mon, 2013-07-15 at 14:44 -0700, Greg KH wrote:
I don't like this at all, just for the simple reason
On Mon, 2013-07-15 at 23:20 -0700, Greg KH wrote:
On Tue, Jul 16, 2013 at 09:17:32AM +0400, James Bottomley wrote:
On Mon, 2013-07-15 at 14:44 -0700, Greg KH wrote:
On Mon, Jul 15, 2013 at 11:27:56PM +0400, James Bottomley wrote:
Before the 3.10.1-stable review thread degenerated into a
On Mon, 15 Jul 2013, H. Peter Anvin wrote:
Perhaps the KS topic should be about different stable workflows and what
the maintainers' options are, rather than about a specific proposal.
This seems like a good discussion topic.
I agree as well; I believe all the proposals related to -stable can
On Mon, 15 Jul 2013, Greg KH wrote:
Anything that's being reviewed on the stable list is public. I know
this is an old argument, but if you point out a fix you *know* has a
security impact then you'll help general distribution maintainers and
users a lot more than you help the black-hats
On Tue, Jul 16, 2013 at 03:00:29AM +0100, Ben Hutchings wrote:
On Mon, 2013-07-15 at 23:27 +0400, James Bottomley wrote:
The problem, as Jiří Kosina put is succinctly is that the distributions
are finding stable less useful because it contains to much stuff they'd
classify as not stable
On Mon 15-07-13 23:20:58, Greg KH wrote:
I think the real stable issue that _everyone_ keeps ignoring, is my
original complaint, in that people are using the -rc1 merge window to
get fixes in they should have sent to Linus for .0.
I don't see anything you have written so far that will help
On Tue, 2013-07-16 at 11:46 +0200, Jiri Kosina wrote:
On Tue, 16 Jul 2013, James Bottomley wrote:
But I need, from the distros, specific examples of what they object to.
So far all I've gotten is one security patch (that was needed), and one
patch for sysfs that I backported too far in
On Tue, Jul 16, 2013 at 3:43 AM, James Bottomley
james.bottom...@hansenpartnership.com wrote:
On Mon, 2013-07-15 at 23:20 -0700, Greg KH wrote:
On Tue, Jul 16, 2013 at 09:17:32AM +0400, James Bottomley wrote:
On Mon, 2013-07-15 at 14:44 -0700, Greg KH wrote:
On Mon, Jul 15, 2013 at
On 13-07-15 08:25 PM, H. Peter Anvin wrote:
On 07/15/2013 05:21 PM, Greg KH wrote:
However, it doesn't seem to happen too often, but it does underscore the
need for a maintainer to be able to *retroactively* NAK a patch for
stable, if it is uncovered that it isn't appropriate after all.
I
On Tue, Jul 16, 2013 at 11:46:05AM +0200, Jiri Kosina wrote:
On Tue, 16 Jul 2013, James Bottomley wrote:
But I need, from the distros, specific examples of what they object to.
So far all I've gotten is one security patch (that was needed), and one
patch for sysfs that I backported too
On Tue, Jul 16, 2013 at 11:11:24AM +0200, Jiri Kosina wrote:
On Mon, 15 Jul 2013, Greg KH wrote:
Anything that's being reviewed on the stable list is public. I know
this is an old argument, but if you point out a fix you *know* has a
security impact then you'll help general
On Mon, 2013-07-15 at 23:24 -0700, David Lang wrote:
Just because some crazy person ;-) decides to maintain 2.4 for many years
doesn't mean that every subsystem maintainer needs to worry about backporting
patches from 3.11 all the way back to 2.4. The fact that they are as willing
as
On Tue, 16 Jul 2013, Greg KH wrote:
But I need, from the distros, specific examples of what they object to.
So far all I've gotten is one security patch (that was needed), and one
patch for sysfs that I backported too far in the version numbers (my
fault.)
Given the huge
On Tue, 2013-07-16 at 09:36 -0700, Greg KH wrote:
On Tue, Jul 16, 2013 at 11:11:24AM +0200, Jiri Kosina wrote:
On Mon, 15 Jul 2013, Greg KH wrote:
Anything that's being reviewed on the stable list is public. I know
this is an old argument, but if you point out a fix you *know* has a
On Wed, Jul 17, 2013 at 04:53:58AM +0100, Ben Hutchings wrote:
On Tue, 2013-07-16 at 09:36 -0700, Greg KH wrote:
On Tue, Jul 16, 2013 at 11:11:24AM +0200, Jiri Kosina wrote:
On Mon, 15 Jul 2013, Greg KH wrote:
Anything that's being reviewed on the stable list is public. I know
On Mon, 2013-07-15 at 23:27 +0400, James Bottomley wrote:
Before the 3.10.1-stable review thread degenerated into a disagreement
about habits of politeness, there were some solid points being made
which, I think, bear consideration and which may now be lost.
Party pooper ;-)
The problem,
Hi Steven,
On Mon, Jul 15, 2013 at 03:45:17PM -0400, Steven Rostedt wrote:
How about this as a proposal.
Keep the Cc: stable@ tag as it is today.
Have Greg, or whoever, change his script to not take commits marked for
stable, but instead, forward the commit to the maintainer. Or as it
On Mon, Jul 15, 2013 at 03:45:17PM -0400, Steven Rostedt wrote:
Have Greg, or whoever, change his script to not take commits marked for
stable, but instead, forward the commit to the maintainer. Or as it
already does today, to everyone on the Cc, and -by: tags. Change the
script from being
On Mon, Jul 15, 2013 at 11:27:56PM +0400, James Bottomley wrote:
[ ... ]
The solution, to me, looks simple: Let's co-opt a process we already
know how to do: mailing list review and tree handling. So the proposal
is simple:
1. Drop the cc: stable@ tag: it makes it way too easy to
On Mon, 2013-07-15 at 21:55 +0200, Willy Tarreau wrote:
I disagree with your proposal. All these points are already covered by
the stable review and the early notification that the greg-bot does when
the patch is included in the queue. If submitters/maintainers do not read
these e-mails sent
On Mon, 2013-07-15 at 21:15 +0100, Mark Brown wrote:
One thing I don't particularly like about this is having to resend the
patches in response to mail; it seems cumbersome to do that rather than
reply to mail or something. Requiring a positive acknowledgement or
action seems useful but the
On Mon, 2013-07-15 at 16:56 -0400, Steven Rostedt wrote:
It may not be efficient for maintainers, but as maintainers we should
spend a bit more time on stable releases.
The MAINTAINERS file specifies a difference between a
section that's Maintained vs Supported.
Do please remember there's a
On Mon, 2013-07-15 at 14:09 -0700, Joe Perches wrote:
On Mon, 2013-07-15 at 16:56 -0400, Steven Rostedt wrote:
It may not be efficient for maintainers, but as maintainers we should
spend a bit more time on stable releases.
The MAINTAINERS file specifies a difference between a
section
On Mon, 2013-07-15 at 17:21 -0400, Steven Rostedt wrote:
How many maintainers are really just volunteers?
No idea. Here's a data point.
$ git grep ^S: MAINTAINERS|sed -r 's/\s+/ /g'|sort|uniq -c|sort -rn
818 MAINTAINERS:S: Maintained
248 MAINTAINERS:S: Supported
49 MAINTAINERS:S:
On Mon, Jul 15, 2013 at 04:56:19PM -0400, Steven Rostedt wrote:
I'm temporarily maintaining a 3.6 stable release (can't wait till I
don't have to do that anymore). And I cheat. I use the trees that Greg
uses, and I still spend days getting it ready.
I've been doing the same for a long time
On Mon, 2013-07-15 at 14:44 -0700, Greg KH wrote:
I don't like this at all, just for the simple reason that it will push
the majority of the work of stable kernel development on to the
subsystem maintainers, who have enough work to do as it is.
Stable tree stuff should cause almost _no_
On Mon, 2013-07-15 at 13:19 -0700, Guenter Roeck wrote:
That seems to be a bit drastic. It is quite useful to have the tag,
but maybe it should only be added by the maintainer and not in the initial
patch submission. This would ensure that the maintainer(s) made the decision.
If the original
On Mon, Jul 15, 2013 at 11:04:28PM +0100, David Woodhouse wrote:
On Mon, 2013-07-15 at 13:19 -0700, Guenter Roeck wrote:
That seems to be a bit drastic. It is quite useful to have the tag,
but maybe it should only be added by the maintainer and not in the initial
patch submission. This
On Mon, 15 Jul 2013, Greg KH wrote:
The solution, to me, looks simple: Let's co-opt a process we already
know how to do: mailing list review and tree handling. So the proposal
is simple:
1. Drop the cc: stable@ tag: it makes it way too easy to add an ill
reviewed patch
On 07/15/2013 03:07 PM, Guenter Roeck wrote:
On Mon, Jul 15, 2013 at 11:04:28PM +0100, David Woodhouse wrote:
On Mon, 2013-07-15 at 13:19 -0700, Guenter Roeck wrote:
That seems to be a bit drastic. It is quite useful to have the tag,
but maybe it should only be added by the maintainer and not
On Mon, Jul 15, 2013 at 03:38:08PM -0700, H. Peter Anvin wrote:
On 07/15/2013 03:07 PM, Guenter Roeck wrote:
On Mon, Jul 15, 2013 at 11:04:28PM +0100, David Woodhouse wrote:
On Mon, 2013-07-15 at 13:19 -0700, Guenter Roeck wrote:
That seems to be a bit drastic. It is quite useful to have
On Mon, Jul 15, 2013 at 06:01:39PM -0400, Steven Rostedt wrote:
On Mon, 2013-07-15 at 14:44 -0700, Greg KH wrote:
I don't like this at all, just for the simple reason that it will push
the majority of the work of stable kernel development on to the
subsystem maintainers, who have enough
On Tue, Jul 16, 2013 at 12:22:16AM +0200, Jiri Kosina wrote:
On Mon, 15 Jul 2013, Greg KH wrote:
The solution, to me, looks simple: Let's co-opt a process we already
know how to do: mailing list review and tree handling. So the proposal
is simple:
1. Drop the cc: stable@
On 07/15/2013 04:22 PM, Guenter Roeck wrote:
I agree, _should_. But again, that is not the point I was trying to make.
The keyword is _active_ decision vs. passive acceptance of a stable tag.
If the stable tag is not added by the maintainer, it can always be added to
the stable queue after
On Mon, Jul 15, 2013 at 05:13:42PM -0700, H. Peter Anvin wrote:
On 07/15/2013 04:22 PM, Guenter Roeck wrote:
I agree, _should_. But again, that is not the point I was trying to make.
The keyword is _active_ decision vs. passive acceptance of a stable tag.
If the stable tag is not
On 07/15/2013 05:21 PM, Greg KH wrote:
However, it doesn't seem to happen too often, but it does underscore the
need for a maintainer to be able to *retroactively* NAK a patch for
stable, if it is uncovered that it isn't appropriate after all.
I give maintainers 2 different chances to NAK a
On Monday, July 15, 2013 04:08:25 PM Greg KH wrote:
On Mon, Jul 15, 2013 at 03:01:18PM -0700, H. Peter Anvin wrote:
Perhaps the KS topic should be about different stable workflows and what
the maintainers' options are, rather than about a specific proposal.
This seems like a good discussion
On Mon, 2013-07-15 at 23:27 +0400, James Bottomley wrote:
Before the 3.10.1-stable review thread degenerated into a disagreement
about habits of politeness, there were some solid points being made
which, I think, bear consideration and which may now be lost.
The problem, as Jiří Kosina put
On Mon, 2013-07-15 at 17:06 -0700, Greg KH wrote:
Maintainers are our most limited resource, I'm getting their ack when
they themselves tag the patch to be backported with the Cc: line.
I find stable maintainers even more limited.
I'm not sure our maintainers are the most limited resource, we
On Mon, 2013-07-15 at 14:44 -0700, Greg KH wrote:
[...]
The second one is almost always due to security issues that were unknown
to the distro. The announcement of security problems to the distros has
now been addressed, and since that has changed, I haven't heard any
problems about this.
On Tue, Jul 16, 2013 at 12:41 PM, Ben Hutchings b...@decadent.org.uk wrote:
On Mon, 2013-07-15 at 22:09 -0400, Steven Rostedt wrote:
[...]
How important is the stable releases? Are maintainers willing to do a
little more work now to make sure their subsystems work fine in older
kernels?
On Tue, 2013-07-16 at 13:27 +1000, Dave Airlie wrote:
I also heard some managers decided their kernel source packages should
have all the patches squashed together to make them harder to cherry-
pick... could it have been the same company?
Greg loves to tell stories about RH management,
On Tue, 2013-07-16 at 13:27 +1000, Dave Airlie wrote:
On Tue, Jul 16, 2013 at 12:41 PM, Ben Hutchings b...@decadent.org.uk wrote:
On Mon, 2013-07-15 at 22:09 -0400, Steven Rostedt wrote:
[...]
How important is the stable releases? Are maintainers willing to do a
little more work now
54 matches
Mail list logo
