[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150408101616.GF5162@x1>
Date: Wed, 8 Apr 2015 11:16:16 +0100
From: Lee Jones <lee.jones@...aro.org>
To: Pavel Machek <pavel@....cz>
Cc: Eduardo Valentin <edubezval@...il.com>, ajitpal.singh@...com,
rui.zhang@...el.com, linux-kernel@...r.kernel.org
Subject: Re: patch "drivers: thermal: st: remove several sparse warnings"
added to thermal-soc tree
On Wed, 08 Apr 2015, Pavel Machek wrote:
> On Wed 2015-04-08 10:45:07, Lee Jones wrote:
> > On Wed, 08 Apr 2015, Pavel Machek wrote:
> >
> > > On Wed 2015-04-08 08:26:34, Lee Jones wrote:
> > > > On Tue, 07 Apr 2015, Eduardo Valentin wrote:
> > > >
> > > > >
> > > > > This is a simple automated notification to let you know that
> > > > > I've just added the patch titled
> > > > >
> > > > > drivers: thermal: st: remove several sparse warnings
> > > > >
> > > > > to my thermal-soc git tree which can be found at
> > > > > git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git
> > > > > in the fixes branch.
> > > > >
> > > > > The patch will show up in the next release of the linux-next tree
> > > > > (usually sometime within the next 24 hours during the week.)
> > > > >
> > > > > The patch will hopefully also be merged in Linus's tree for the
> > > > > next -rc kernel release.
> > > > >
> > > > > If you have any questions about this process, please let me know.
> > > > >
> > > > > All the best,
> > > > >
> > > > > Eduardo Valentin
> > > > >
> > > > > ----------
> > > > > From 541d529f9845d249d1cb84f1b395e48f0a117e3f Mon Sep 17 00:00:00 2001
> > > > > From: Eduardo Valentin <edubezval@...il.com>
> > > > > Date: Tue, 7 Apr 2015 13:42:12 -0700
> > > > > Subject: drivers: thermal: st: remove several sparse warnings
> > > > >
> > > > > Simple patch to make symbols static. Symbols that are not
> > > > > shared with other parts of the kernel can be made static.
> > > > > This change also removes several sparse complains.
> > > > >
> > > > > Cc: Zhang Rui <rui.zhang@...el.com>
> > > > > Cc: Lee Jones <lee.jones@...aro.org>
> > > > > Cc: Pavel Machek <pavel@....cz>
> > > > > Cc: Ajit Pal Singh <ajitpal.singh@...com>
> > > > > Cc: linux-pm@...r.kernel.org
> > > > > Cc: linux-kernel@...r.kernel.org
> > > >
> > > > Hold on a second, you can't do that.
> > > >
> > > > Adding these Cc: tags means "this person has been given the opportunity
> > > > to comment on the patch but has chosen not to". However, you've
> > > > applied this patch ~1min after sending it to the lists.
> > >
> > > Cc means -- that person was Cced.
> >
> > You just made that up out of thin air. That's not what it means at all.
> >
> > Documentation/SubmittingPatches:
> >
> > "If a person has had the opportunity to comment on a patch,
> > but has not provided such comments, you may optionally add a
> > "Cc:" tag to the patch. This is the only tag which might be
> > added without an explicit action by the person it names - but
> > it should indicate that this person was copied on the patch.
> > This tag documents that potentially interested parties have
> > been included in the discussion."
> >
> > To add people on Cc, then immediately apply the patch is fundamentally
> > wrong.
>
> That is not how I seen it working before.
But now you know what they are meant to be for and you can spread the
word appropriately.
> > > And there's no harm in having patch available in git for easy testing.
> >
> > If we weren't so deep into the release cycle, I'd agree with you. But
> > even if we weren't so close to the merge-window, I'd still expect a
> > note to the tune of "tentatively applying this for reason X for early
> > soak testing in -next". Although X would have to be a pretty good
> > reason, as that's not usually how we do things.
>
> Patches should spend a week or so in -next (that's documented
> somewhere), so people in the Cc list will have their chance to
> comment.
Yes they should, _after_ reviewing. Chucking patches into -next
before others have been given a chance to review is _not_ the right
thing to do. If everyone did that -next would be unbuildable and
unusable. Patches should only be sucked into -next when a certain
level of quality has been reached. That level is obtained in our case
by peer review.
I've said my piece on this now and shall not be discussing it further,
as I have proper work to be getting on with.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists