|
It wouldn't be a Weekly Edition without a flame war over styleIt wouldn't be a Weekly Edition without a flame war over stylePosted Mar 27, 2008 7:48 UTC (Thu) by bangert (subscriber, #28342)In reply to: It wouldn't be a Weekly Edition without a flame war over style by pr1268 Parent article: Quotes of the week
> to willfully "violate the style. Just to spite the fundamentalist > movement" is equally fundamentalist.
(Log in to post comments)
It wouldn't be a Weekly Edition without a flame war over style Posted Mar 27, 2008 12:15 UTC (Thu) by mingo (subscriber, #31122) [Link] yes - and in arch/x86 (where this discussion originated from) we do not actually reject patches based on style issues - we either fix it ourselves if it's easy, or we ask people to fix them up and if they refuse it we still do it ourselves. So far out of the more than hundred arch/x86 contributors in v2.6.25 (who authored over 1200 arch/x86 changes since v2.6.24) it happened only once that a cleanup request from us x86 maintainers was refused. In that case we simply cleaned up the patches ourselves. There's not a single arch/x86 patch that has been submitted to lkml that is not in x86.git right now which has been rejected for pure style issues. People actually like consistent code, they like if code "looks nice" throughout a subsystem, and they like the increased maintainability and lower bug rate this brings. It just needs maintainers and tools reminding people of that in a neutral, objective, non-intrusive and non-workflow-impacting but still persistent manner. It's easy to get non-functional components of source code wrong, it happens to oldtimers just as much as newbies. This discussion IMHO is more about those maintainers who have a gut reaction against like the bad news that a "scripts/checkpatch.pl --file */*.c" run brings when they run it over their own files. As someone who has fixed literally thousands of style issues i certainly know that "oh no!" feeling! :-)
It wouldn't be a Weekly Edition without a flame war over style Posted Mar 27, 2008 12:38 UTC (Thu) by hmh (subscriber, #3838) [Link] Heh. Shadows of the Debian dpkg mess with Ian. The difference here is that you guys are much faster at the "cleanup the foreign mess and merge" important step, AND that there is absolutely no small hole someone could try to pry open in order to get one of the worst git history mess I have ever seen merged directly into mainline. Kudos to the arch/x86 maintainers.
|
Copyright © 2008, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds
Powered by Rackspace Managed Hosting.