Prev: [tip:x86/uv] x86, UV: BAU structure rearranging
Next: [PATCH v2] x86: Unify dumpstack.h and stacktrace.h
From: Greg KH on 9 Jun 2010 11:10 On Wed, Jun 09, 2010 at 03:24:51PM +0200, Arnd Bergmann wrote: > On Wednesday 09 June 2010, Greg KH wrote: > > > > I also found it a bit odd you didn't send these to the stable subsystem > > > > maintainer, why? > > > > > > The MAINTAINERS patches are forward going, not historical. > > > > What does that mean? > > I guess you meant to write '... to the /staging/ subsystem maintainer'. Doh, yes, you are right. Joe, why didn't you send these to the "STAGING" subsystem maintainer? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Joe Perches on 9 Jun 2010 12:00 On Wed, 2010-06-09 at 08:08 -0700, Greg KH wrote: > On Wed, Jun 09, 2010 at 03:24:51PM +0200, Arnd Bergmann wrote: > > On Wednesday 09 June 2010, Greg KH wrote: > > > > > I also found it a bit odd you didn't send these to the stable subsystem > > > > > maintainer, why? > > > > The MAINTAINERS patches are forward going, not historical. > > > What does that mean? > > I guess you meant to write '... to the /staging/ subsystem maintainer'. > Doh, yes, you are right. > Joe, why didn't you send these to the "STAGING" subsystem maintainer? Gee, who would that be? Why be so indirect? (Even though you are both the stable and the staging maintainer) Why don't you just write "How come I didn't get cc'd?" I'm the closest thing there is to a MAINTAINERS maintainer. Andrew has taken all the patches I've posted to it except for the patchset that added file patterns and you're rarely a path to get things into MAINTAINERS. $ ./scripts/get_maintainer.pl -f --rolestats MAINTAINERS Andrew Morton <akpm(a)linux-foundation.org> (commit_signer:97/515=19%) Joe Perches <joe(a)perches.com> (commit_signer:83/515=16%) "David S. Miller" <davem(a)davemloft.net> (commit_signer:35/515=7%) And you already had written that you wouldn't take a similar individual patch. http://lkml.org/lkml/2010/6/2/428 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Greg KH on 9 Jun 2010 12:10 On Wed, Jun 09, 2010 at 08:52:24AM -0700, Joe Perches wrote: > On Wed, 2010-06-09 at 08:08 -0700, Greg KH wrote: > > On Wed, Jun 09, 2010 at 03:24:51PM +0200, Arnd Bergmann wrote: > > > On Wednesday 09 June 2010, Greg KH wrote: > > > > > > I also found it a bit odd you didn't send these to the stable subsystem > > > > > > maintainer, why? > > > > > The MAINTAINERS patches are forward going, not historical. > > > > What does that mean? > > > I guess you meant to write '... to the /staging/ subsystem maintainer'. > > Doh, yes, you are right. > > Joe, why didn't you send these to the "STAGING" subsystem maintainer? > > Gee, who would that be? Why be so indirect? > (Even though you are both the stable and the staging maintainer) > > Why don't you just write "How come I didn't get cc'd?" Because I was trying to point out that you are ignoring the maintainer of the subsystem for which you are adding entries for. In fact, going against the wishes of that maintainer (i.e. me) at the same time. > I'm the closest thing there is to a MAINTAINERS maintainer. > Andrew has taken all the patches I've posted to it except for > the patchset that added file patterns and you're rarely a > path to get things into MAINTAINERS. That's great and wonderful, and you do a great job. But that has little to do with this. > And you already had written that you wouldn't take a > similar individual patch. > > http://lkml.org/lkml/2010/6/2/428 Exactly. For the reasons stated previously. If you are going to be responsible for keeping these up to date, especially when the drivers go away or move, then fine, make these changes. But if not, then don't accept them, as I'm not going to. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Joe Perches on 9 Jun 2010 12:30 On Wed, 2010-06-09 at 09:01 -0700, Greg KH wrote: > I was trying to point out that you are ignoring the maintainer > of the subsystem for which you are adding entries for. In fact, going > against the wishes of that maintainer (i.e. me) at the same time. > > I'm the closest thing there is to a MAINTAINERS maintainer. > > Andrew has taken all the patches I've posted to it except for > > the patchset that added file patterns and you're rarely a > > path to get things into MAINTAINERS. [] > But that has little to do with this. Of course it does. Without these patches, people have to look in multiple places to determine where best to send patches and get_maintainers.pl produces poorer results. The centralization is good, the redundancy is low, and I like it when tools produce good results. It seems you produce fewer satisfaction endorphins from that than I. ;) > If you are going to be responsible for keeping these up to date, > especially when the drivers go away or move, then fine, make these > changes. Yup, I do that and will likely continue to do so. I occasionally run scripts that sieve MAINTAINERS file patterns against the current tree and highlight what's renamed or removed. Then I post patches. > But if not, then don't accept them, as I'm not going to. Who are you writing that to? Me? Linus doesn't pull from me. Anyway no worries Greg. Life's good. Hope your enjoyment endorphin receptors are always active... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
First
|
Prev
|
Pages: 1 2 Prev: [tip:x86/uv] x86, UV: BAU structure rearranging Next: [PATCH v2] x86: Unify dumpstack.h and stacktrace.h |