The v4l-dvb git tree is where changesets go before Mauro requests a
merge to Linus. This repository is usually months behind the current
development tree, and for good reason.
Mauro's 'devel' branch is relatively close to the mercurial repository,
however, in the mercurial repository we maintain backwards compatibility
that usually goes back at least a few kernel versions. In order to
support that compatibility, there are extra #ifdef compiler directives
in that source tree, which is stripped away before merging to -git.
When large patches come in based on the git repositories, a large amount
of manual application is needed in order to merge properly. This is
usually only an issue for large, frivolous coding style changes. Most
functional patches never hit this issue.
You misunderstood me. I was talking about how people can compile the
sources using __func__ rather than __FUNCTION__ using older compilers
that do not support __func__.
Meanwhile -- you just pointed out this trap, above. If that is already
in kernel.h, then why replace all actual occurences of __FUNCTION__ with
__func__ across the kernel tree? That trap allows your cleanup to take
affect in the compiled binaries, while NOT forcing this change on the
subsystem kernel code.
The v4l-dvb tree is used outside of the kernel as well as within the
kernel, and we like to support additional configurations that are not
necessarily supported in-kernel.
This conversion "cleanup" is starting to sound less and less
attractive. Was there ever a discussion & agreement about this on LKML??
place?
I'm guessing that this discussion never actually took place?
Please see my comments at the end of this email.
No. A git mirror would not help in this case, since we would need to
merge the changes back into the mercurial repository before the changes
waiting there go to -git.
It's not that I "really want such a patch" -- rather, I am merely
reacting in the same manner that has been done in the past.
For example:
Quite often the case arises where a user reports an OOPS, or some other
bug in the current code. A developer will fix the bug, and send in a
patch to fix it. The maintainer of our subsystem then proceeds to NACK
the bug-fix patch, because it fails checkpatch.pl.
I disagree with this policy, however, this is the policy. I always felt
that patches should be small, and only attack one specific item. I have
always agreed with akpm's "The Perfect Patch" document, where no two
changes should ever appear in the same patch. ie: if there is a
codingstyle / whitespace cleanup, it should appear in a separate patch,
rather than a patch that fixes a bug or adds new functionality.
Ever since the appearance of checkpatch.pl, now all patches that fix
real bugs get nacked unless they themselves pass checkpatch.pl's
"requirements". The patch must be re-worked, or an additional patch
must be submitted, that removes any codingstyle issue detected by the
original patch, even if it is caused by a piece of code that had already
existed.
In summary, I as a developer, am made aware of bugs in the kernel, and I
like to fix them when I can. When I submit a bug-fix patch that alters
a line that has comma's without spaces afterwards, my patch is nacked,
until I fix the codingstyle issue as well, even though the codingstyle
issue pre-dates my own patch.
If I can't submit a bug-fix without being held up to checkpatch.pl ,
then those same requirements must be upheld by trivial, frivolous coding
style "cleanups" as well.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Harvey, I know you mean well, and I thank you for that. I hope you
understand my point of view.
Regards,
Mike
--
