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 f
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 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, tel
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 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 queue
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
it to
Linux.conf.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 patc
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
al 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
+ 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, provid
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,
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 sen
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, 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
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 r
21 matches
Mail list logo
