From: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: James Bottomley <James.Bottomley@hansenpartnership.com>,
ksummit <ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Pull network and Patch Acceptance Consistency
Date: Thu, 13 Jun 2019 10:49:30 -0300 [thread overview]
Message-ID: <20190613104930.7dc85e13@coco.lan> (raw)
In-Reply-To: <yq17e9xi24p.fsf@oracle.com>
Em Fri, 07 Jun 2019 16:14:46 -0400
"Martin K. Petersen" <martin.petersen@oracle.com> escreveu:
> Dan,
>
> > That said, I do think moving forward with the document would be
> > necessary pre-work for this conversation. Just the act of putting
> > subsystem specific policies in writing even if they differ would go
> > along way towards making the lives of contributors less fraught with
> > arbitrary peril.
>
> I think part of the problem is that some subsystems are older than
> others.
>
> It is much easier to enforce your favorite bike shed/Xmas tree if the
> code is very similar and developed by like-minded people. Or written in
> this millennium.
>
> Whereas in SCSI I have 25+ years of changes in coding practices,
> numerous vendor drivers influenced by styles in various other operating
> systems, etc. to deal with.
>
> I try to enforce current best practices on core code because that is a
> very limited subset. And one which I can micro-manage. But trying to
> enforce similar rules on old crusty stuff which probably has no active
> maintainer is fraught with error. Plus things become completely
> unreadable if you start mixing new and 25+ year old style inside a
> single file.
>
> So I am perfectly OK with having policies. But communicating and
> enforcing them on a per-subsystem basis is too coarse a granularity for
> the reality I have to deal with. Consequently, I think your MAINTAINERS
> tagging idea is a good approach.
>
That's true, but it doesn't mean that those old style subsystems
can't be improved.
In the case of media we have 20+ years of changes. So, the received code
had a myriad of different coding styles.
Yet, we do enforce the current coding practices to all new code
we receive.
Also, at least at the core (and on some drivers that people use as
reference for new codes), when we receive patches that do a large
amount of changes at the code, and we have some spare time, we run
checkpatch.pl at the entire affected file, and we fix the style as
much as possible[1].
Yeah, that's painful, but as we do such practices for quite sime time,
nowadays the code gets improved and now people tend to do first time
submissions using the current style practices.
[1] We usually ignore 80 column warnings on legacy code though,
as a proper fix would mean to rewrite the code in order to split
functions into smaller ones, with could cause regressions.
Thanks,
Mauro
next prev parent reply other threads:[~2019-06-13 13:49 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-06 15:48 James Bottomley
2019-06-06 15:58 ` Greg KH
2019-06-06 16:24 ` James Bottomley
2019-06-13 13:59 ` Mauro Carvalho Chehab
2019-06-14 10:12 ` Laurent Pinchart
2019-06-14 13:24 ` Mauro Carvalho Chehab
2019-06-14 13:31 ` Laurent Pinchart
2019-06-14 13:54 ` Mauro Carvalho Chehab
2019-06-14 14:08 ` Laurent Pinchart
2019-06-14 14:56 ` Mark Brown
2019-06-14 13:58 ` Greg KH
2019-06-14 15:11 ` Mauro Carvalho Chehab
2019-06-14 15:23 ` James Bottomley
2019-06-14 15:43 ` Mauro Carvalho Chehab
2019-06-14 15:49 ` James Bottomley
2019-06-14 16:04 ` Mauro Carvalho Chehab
2019-06-14 16:16 ` James Bottomley
2019-06-14 17:48 ` Mauro Carvalho Chehab
2019-06-17 7:01 ` Geert Uytterhoeven
2019-06-17 13:31 ` Mauro Carvalho Chehab
2019-06-17 14:26 ` Takashi Iwai
2019-06-19 7:53 ` Dan Carpenter
2019-06-19 8:13 ` [Ksummit-discuss] [kbuild] " Philip Li
2019-06-19 8:33 ` [Ksummit-discuss] " Daniel Vetter
2019-06-19 14:39 ` Mauro Carvalho Chehab
2019-06-19 14:48 ` [Ksummit-discuss] [media-submaintainers] " Laurent Pinchart
2019-06-19 15:19 ` Mauro Carvalho Chehab
2019-06-19 15:46 ` James Bottomley
2019-06-19 16:23 ` Mark Brown
2019-06-20 12:24 ` Geert Uytterhoeven
2019-06-20 10:36 ` Jani Nikula
2019-06-19 15:56 ` Mark Brown
2019-06-19 16:09 ` Laurent Pinchart
2019-06-15 10:55 ` [Ksummit-discuss] " Daniel Vetter
2019-06-14 20:52 ` Vlastimil Babka
2019-06-15 11:01 ` Laurent Pinchart
2019-06-17 11:03 ` Mauro Carvalho Chehab
2019-06-17 12:28 ` Mark Brown
2019-06-17 16:48 ` Tim.Bird
2019-06-17 17:23 ` Geert Uytterhoeven
2019-06-17 23:13 ` Mauro Carvalho Chehab
2019-06-17 14:18 ` Laurent Pinchart
2019-06-06 16:29 ` James Bottomley
2019-06-06 18:26 ` Dan Williams
2019-06-07 20:14 ` Martin K. Petersen
2019-06-13 13:49 ` Mauro Carvalho Chehab [this message]
2019-06-13 14:35 ` James Bottomley
2019-06-13 15:03 ` Martin K. Petersen
2019-06-13 15:21 ` Bart Van Assche
2019-06-13 15:27 ` James Bottomley
2019-06-13 15:35 ` Guenter Roeck
2019-06-13 15:39 ` Bart Van Assche
2019-06-14 11:53 ` Leon Romanovsky
2019-06-14 17:06 ` Bart Van Assche
2019-06-15 7:20 ` Leon Romanovsky
2019-06-13 15:39 ` James Bottomley
2019-06-13 15:42 ` Takashi Iwai
2019-06-13 19:28 ` James Bottomley
2019-06-14 9:08 ` Dan Carpenter
2019-06-14 9:43 ` Dan Carpenter
2019-06-14 13:27 ` Dan Carpenter
2019-06-13 17:27 ` Mauro Carvalho Chehab
2019-06-13 18:41 ` James Bottomley
2019-06-13 19:11 ` Mauro Carvalho Chehab
2019-06-13 19:20 ` Joe Perches
2019-06-14 2:21 ` Mauro Carvalho Chehab
2019-06-13 19:57 ` Martin K. Petersen
2019-06-13 14:53 ` Martin K. Petersen
2019-06-13 17:09 ` Mauro Carvalho Chehab
2019-06-14 3:03 ` Martin K. Petersen
2019-06-14 3:35 ` Mauro Carvalho Chehab
2019-06-14 7:31 ` Joe Perches
2019-06-13 13:28 ` Mauro Carvalho Chehab
2019-06-06 16:18 ` Bart Van Assche
2019-06-14 19:53 ` Bjorn Helgaas
2019-06-14 23:21 ` Bjorn Helgaas
2019-06-17 10:35 ` Mauro Carvalho Chehab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190613104930.7dc85e13@coco.lan \
--to=mchehab+samsung@kernel.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=martin.petersen@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox