Post by Tim Bird Post by David Seikel Post by Tim Bird
It is better to provide the patch inline, in the message body, rather
than as an attachment. This allows people to easily respond to
individual parts of the patch by commenting directly in a response
e-mail. Comments can be placed in-line with the submitted code.
I thought it was generally agreed that attached patches are better
than inlined ones. Inline patches can get mangled to the point where
the patch program fails to actually use them. Attached patches are a
separate item that wont get mangled. Look back in this list you will
see inline patches that had this problem. Having the patch actually
work is more important than the ability to comment on them in place.
In my experience with mailing lists where the patch is sent to the list
by the source code management tool, people usually just quote the
entire patch as one big blob when commenting on it. Even if the patch
is megabytes long, and their response is two or three words.
Those are some good pros and cons for the different approaches.
I'm coming from a kernel development experience, where inline is
preferred. I'll admit it is a bit of a pain to inline the patch
properly with modern mailers (there always seems to be some kind
of tab replacement, leading or trailing whitespace, or line wrapping
issue that someone's mailer does without their consent and which
mangles the patch.) However, commenting on a single line of
an attached patch is pretty annoying.
Works for me...
Post by Tim Bird
I'm hoping the patches here are not megabytes long. That would seem to
defeat the purpose of the project. :-)
The linux kernel rules are all about scaling to huge volumes. This
project is about carefully crafting something small, in the
dorodango/bonsai sense. The kernel guys are trying to make a saturn
rocket and I'm trying to build a ship in a bottle or one of the original
(I note that one of the many time sinks I've been juggling is
linux-kernel Documentation maintainer, where recent commits to
SubmittingPatches wandered by I had to review. I actually need to get my
kernel.org account back but the hoops you have to jump through now that
they're locking the barn door after the horses escaped is just
ridiculous, and last night's hour of energy after work went to toybox,
and this morning's half hour of time before work is going to toybox
email, and what's left _over_ goes to aboriginal so I can use it to test
Post by Tim Bird
This is Rob's project so I guess we should just go with whatever
his preference is.
I care about the code. The submission process is secondary. Even busybox
never quite scaled its development community to the point where patch
flooding was a serious problem and they had to streamline it.
It was a good patch, I merged it. And then I did the cleanup Andre
suggested (although I hadn't read his mail yet when I did it. :)
I actually prefer to merge submissions as-is and then do my cleanups on
top of them for attribution reasons. 2-clause BSD renders ownership
moot, but attribution is very important.
That's actually why I like the "hg export" patches, because then the
metadata says it's from them instead of from me. (I can note it by hand
in the comment, but it's not the same...)
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.