Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Bug-introducing patches

[Mauro Carvalho Chehab <mchehab+samsung@kernel.org>]

Em Fri, 7 Sep 2018 09:17:18 -0700
Linus Torvalds <torvalds@linux-foundation.org> escreveu:

> On Fri, Sep 7, 2018 at 8:52 AM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:

> And for maintainers, it can be the exact reverse. In Vancouver Greg
> said that normally, for him, the merge window is when he can take a
> break, because the bulk of his work is the "leading up to merge
> window" time, since that's when he works with people to set up the
> branches for the next merge window.

That's exactly what I do here :-)

During the merge window, I usually take off my maintainer's hat and
I either do some usespace stuff or do some development myself.

It is not uncommon that, whatever I'm doing during the merge window
would require part of the -rc1 week to finish. So, typically, fixes
start being merged during -rc2 week, meaning that they'll reach
upstream by -rc3 week or later.

From subsystem developer's side, what I notice from my chair is that
most people developing new features work to cope with the Kernel 
merging cycle, meaning that they do their testing and development
focused on getting their stuff merged up to the -rc6 week. The 
vast majority of pull requests I receive are sent during the -rc6
week.

Most of the bug fixes we have actually are discovered from
people are working on new stuff.

Ok, pure bug reports (and fixes) can be merged anytime, but,
due to the core developer's working cycle, in practice that means
that I receive more bug fixes (both critical and non-critical)
late at the -rc cycle.

Thanks,
Mauro