[Toybox] Preferred submission format (was Re: new toy : w command)

[Rob Landley]

On 07/18/2012 04:45 PM, Tim Bird wrote:
> On 07/18/2012 02:09 PM, David Seikel wrote:
>> On Wed, 18 Jul 2012 11:40:59 -0700 Tim Bird <tbird20d at gmail.com> wrote:
>>> 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.

Double click, open with mousepad, copy, paste as quotation:

>         if(x->ut_type==7) {
> 	    xprintf("\n");
>             xprintf("%-9.8s",x->ut_user);
>             xprintf("%-9.8s",x->ut_line);

Works for me...

> 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
swiss watches.

(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
toybox...)

> This is Rob's project so I guess we should just go with whatever
> his preference is.
> 
> Rob?

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...)

>  -- Tim

Rob
-- 
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation.  Pick one.

 1342706446.0