On Tue, May 23, 2017 at 11:31:22AM +0300, Dan Carpenter wrote: > On Tue, May 23, 2017 at 11:19:58AM +0300, Jani Nikula wrote: > > On Fri, 19 May 2017, Dan Carpenter <dan.carpenter@xxxxxxxxxx> wrote: > > > On Fri, May 19, 2017 at 01:08:20PM -0700, Eric Anholt wrote: > > >> OK, that's definitely not how I've read the > > >> Documentation/process/submitting-patches.rst description of the Fixes > > >> tag, which talks about bugs found with git bisect and things that should > > >> go to -stable. I would not have considered what this patch is changing > > >> to be a bug. > > > > > > True. I don't consider this a bug either. I wouldn't have included a > > > Fixes tag. > > > > > > I pretty much agree with the submitting-patches.rst except it should > > > probably say to include it on more stuff. Fixes: tags are required for > > > all bugfixes to netdev for example. > > > > We use Fixes: in drm/i915 to basically indicate that the referenced > > commit has a bug that actually needs to be fixed, this patch is the fix, > > and should go wherever the referenced commit goes. Annotating typo fixes > > and missing static keywords and such is just noise from *our* POV, and > > need to be filtered out. > > Yes, yes. I agree. Fixes should fix a bug. I'm sorry, I didn't read > the original patch carefully, I just saw that people said Fixes meant > backporting to -stable. Yeah we use Fixes: a lot, also to help all our product teams, who have all varying versions of frankenstein kernels. If they cherry-pick some feature from upstream, they need to know which bugfixes to backport. cc: stable is orthogonal to Fixes:, but Fixes should imo indicate a real bugfix (i.e. if you have the first patch, you want all the patches with Fixes: lines referencing that patch). Unfortunately on the mobile/gfx side there's very few customers who just use a stable release, so we need to be rather dutiful with sprinkling Fixes: tags over everything that fixes bugs (but not more, otherwise there's screaming about backporting too much). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
