On Wed, Dec 17, 2014 at 10:52:27AM +0100, Borislav Petkov wrote:
> On Wed, Dec 17, 2014 at 12:14:24AM -0500, Theodore Ts'o wrote:
> > And what's wrong for one maintainer will be right for another, and
> > vice versa.
> Ok, so what's wrong with "should not expect any feedback during the
> merge w
On 18/12/2014 11:42, Borislav Petkov wrote:
> > But a mail from your manager asking to merge a large feature after rc6
> > will definitely make me more grumpy.
>
> I sincerely hope it'll never be the case where managers dictate the
> development on lkml. If this happens, we're terminally screwed.
On Thu, Dec 18, 2014 at 11:35:40AM +0100, Paolo Bonzini wrote:
> But a mail from your manager asking to merge a large feature after rc6
> will definitely make me more grumpy.
I sincerely hope it'll never be the case where managers dictate the
development on lkml. If this happens, we're terminally
On 16/12/2014 19:09, Jonathan Corbet wrote:
> In general, I worry about trying to codify things too much just because
> different maintainers have different expectations. As Linus noted, some
> maintainers have their work done by the time the merge window starts and
> can take patches just fine
On Wed, Dec 17, 2014 at 12:14:24AM -0500, Theodore Ts'o wrote:
> And what's wrong for one maintainer will be right for another, and
> vice versa.
Ok, so what's wrong with "should not expect any feedback during the
merge window"?
If they get it, then that's fine. The formulation is loose on purpo
On Tue, Dec 16, 2014 at 11:31:33PM +0100, Borislav Petkov wrote:
> On Tue, Dec 16, 2014 at 02:19:02PM -0800, Kevin Cernekee wrote:
> > In the current process, many submitters do not know their maintainer's
> > policy until they get in trouble for violating it.
>
> Just say what Christoph suggested
On Tue, Dec 16, 2014 at 02:19:02PM -0800, Kevin Cernekee wrote:
> In the current process, many submitters do not know their maintainer's
> policy until they get in trouble for violating it.
Just say what Christoph suggested: people should not expect any feedback
during the merge window. If they ge
On Tue, Dec 16, 2014 at 10:09 AM, Jonathan Corbet wrote:
> On Sun, 14 Dec 2014 22:09:46 -0800
> Kevin Cernekee wrote:
>
>> This patch series amends the kernel development process to reduce the
>> load on key maintainers during peak periods, by discouraging the submission
>> of non-urgent patches
On Tue, Dec 16, 2014 at 01:09:39PM -0500, Jonathan Corbet wrote:
>
> In general, I worry about trying to codify things too much just because
> different maintainers have different expectations. As Linus noted, some
> maintainers have their work done by the time the merge window starts and
> can t
On Sun, 14 Dec 2014 22:09:46 -0800
Kevin Cernekee wrote:
> This patch series amends the kernel development process to reduce the
> load on key maintainers during peak periods, by discouraging the submission
> of non-urgent patches while the merge window is open.
You do understand the irony of po
10 matches
Mail list logo
