On 18/12/2014 14:25, Fam Zheng wrote:
> > One thing that makes automation a bit easier for QEMU is that it does
> > not have a merge window; while we do have a central committer that takes
> > pull requests, the phases are a bit more traditional (2 month
> > development, 2 weeks preparation for
On 18/12/2014 14:25, Fam Zheng wrote:
One thing that makes automation a bit easier for QEMU is that it does
not have a merge window; while we do have a central committer that takes
pull requests, the phases are a bit more traditional (2 month
development, 2 weeks preparation for freeze,
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
On Thu, 12/18 11:14, Paolo Bonzini wrote:
>
>
> On 13/12/2014 14:52, One Thousand Gnomes wrote:
> > Is it the year for a Google summer of code project or similar to turn
> > patchwork into a proper patch management tool (one that collects the
> > patches, provides a good maintainer interface,
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
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 13/12/2014 14:52, One Thousand Gnomes wrote:
> Is it the year for a Google summer of code project or similar to turn
> patchwork into a proper patch management tool (one that collects the
> patches, provides a good maintainer interface, tells people automatically
> that their patches are
On 13/12/2014 14:52, One Thousand Gnomes wrote:
Is it the year for a Google summer of code project or similar to turn
patchwork into a proper patch management tool (one that collects the
patches, provides a good maintainer interface, tells people automatically
that their patches are queued,
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 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 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.
They
On Thu, 12/18 11:14, Paolo Bonzini wrote:
On 13/12/2014 14:52, One Thousand Gnomes wrote:
Is it the year for a Google summer of code project or similar to turn
patchwork into a proper patch management tool (one that collects the
patches, provides a good maintainer interface, tells
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 window?
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
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 purpose.
f.au sometimes a patch submitter won't get feedback
right away. It's nothing personal.
With all due respect to Steven, I think he over-reacted a little with
his "maintainer abuse" reply. Most of the time people won't get
"yelled" at if they send patches at the wrong time. An
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
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
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
question/reply on something which was discussed
> before.
>
> I really consider it to be maintainer abuse to have
../..
Picking up that thread late ...
I might have myself been the culprit of that and I don't enforce such
policies on devs on powerpc either, as long as they d
on something which was discussed
before.
I really consider it to be maintainer abuse to have
../..
Picking up that thread late ...
I might have myself been the culprit of that and I don't enforce such
policies on devs on powerpc either, as long as they don't have an
expectation of that stuff being
On Sun, 14 Dec 2014 22:09:46 -0800
Kevin Cernekee cerne...@gmail.com 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
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 take
On Tue, Dec 16, 2014 at 10:09 AM, Jonathan Corbet cor...@lwn.net wrote:
On Sun, 14 Dec 2014 22:09:46 -0800
Kevin Cernekee cerne...@gmail.com wrote:
This patch series amends the kernel development process to reduce the
load on key maintainers during peak periods, by discouraging the submission
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 get
get feedback
right away. It's nothing personal.
With all due respect to Steven, I think he over-reacted a little with
his maintainer abuse reply. Most of the time people won't get
yelled at if they send patches at the wrong time. And what's wrong
for one maintainer will be right for another
+ patchwork devs
On Mon, Dec 15, 2014 at 12:15:35PM +0100, Thomas Gleixner wrote:
> On Sat, 13 Dec 2014, One Thousand Gnomes wrote:
> > Is it the year for a Google summer of code project or similar to turn
> > patchwork into a proper patch management tool (one that collects the
> > patches,
On Sat, 13 Dec 2014, One Thousand Gnomes wrote:
> Is it the year for a Google summer of code project or similar to turn
> patchwork into a proper patch management tool (one that collects the
> patches, provides a good maintainer interface, tells people automatically
> that their patches are
On Sat, 13 Dec 2014, One Thousand Gnomes wrote:
Is it the year for a Google summer of code project or similar to turn
patchwork into a proper patch management tool (one that collects the
patches, provides a good maintainer interface, tells people automatically
that their patches are queued,
+ patchwork devs
On Mon, Dec 15, 2014 at 12:15:35PM +0100, Thomas Gleixner wrote:
On Sat, 13 Dec 2014, One Thousand Gnomes wrote:
Is it the year for a Google summer of code project or similar to turn
patchwork into a proper patch management tool (one that collects the
patches, provides a
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.
Original discussion here:
https://lkml.org/lkml/2014/12/12/772
(As a non-subsystem-maintainer I
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.
Original discussion here:
https://lkml.org/lkml/2014/12/12/772
(As a non-subsystem-maintainer I
On Sat, Dec 13, 2014 at 01:52:31PM +, One Thousand Gnomes wrote:
...
> It could then be integrated into git (if only so we can have a "git lost"
> command to block annoying sources)
All sounds nice and good but I'd be fine with people adhering to the
one-week feedback gather rule and not
On Sat, 13 Dec 2014 00:43:36 +0100
Borislav Petkov wrote:
> On Sat, Dec 13, 2014 at 12:24:03AM +0100, Thomas Gleixner wrote:
> > - Posting of massive patch sets right during or just before the merge
> >window
> >
> > - Reposting of patchsets before the reviewer/maintainer had a chance
> >
On Sat, 13 Dec 2014 00:43:36 +0100
Borislav Petkov b...@alien8.de wrote:
On Sat, Dec 13, 2014 at 12:24:03AM +0100, Thomas Gleixner wrote:
- Posting of massive patch sets right during or just before the merge
window
- Reposting of patchsets before the reviewer/maintainer had a
On Sat, Dec 13, 2014 at 01:52:31PM +, One Thousand Gnomes wrote:
...
It could then be integrated into git (if only so we can have a git lost
command to block annoying sources)
All sounds nice and good but I'd be fine with people adhering to the
one-week feedback gather rule and not
On Sat, Dec 13, 2014 at 12:24:03AM +0100, Thomas Gleixner wrote:
> - Posting of massive patch sets right during or just before the merge
>window
>
> - Reposting of patchsets before the reviewer/maintainer had a chance
>to reply to ALL of N patches
Absolutely agreed.
The rule of
it to be maintainer abuse to have
[PATCH V5 00/23] Generic BMIPS kernel
[RFC][PATCH 0/8] x86, mpx: Support 32-bit binaries on 64-bit kernels
[v3 00/26] Add VT-d Posted-Interrupts support
i.e. 57 patches to look at in my inbox TODAY in the middle of the
merge window where I have to make other really
it to be maintainer abuse to have
[PATCH V5 00/23] Generic BMIPS kernel
[RFC][PATCH 0/8] x86, mpx: Support 32-bit binaries on 64-bit kernels
[v3 00/26] Add VT-d Posted-Interrupts support
i.e. 57 patches to look at in my inbox TODAY in the middle of the
merge window where I have to make other really
On Sat, Dec 13, 2014 at 12:24:03AM +0100, Thomas Gleixner wrote:
- Posting of massive patch sets right during or just before the merge
window
- Reposting of patchsets before the reviewer/maintainer had a chance
to reply to ALL of N patches
Absolutely agreed.
The rule of sending out
42 matches
Mail list logo
