Re: [PATCH 0/5] linux-user changes to run docker

["Alex Bennée" <alex.bennee@linaro.org>]

Takashi Yamamoto <yamamoto@midokura.com> writes:

> On Tue, May 25, 2021 at 8:22 AM Takashi Yamamoto <yamamoto@midokura.com> wrote:
>>
>> On Tue, May 25, 2021 at 2:49 AM Alex Bennée <alex.bennee@linaro.org> wrote:
>> >
>> >
>> > YAMAMOTO Takashi <yamamoto@midokura.com> writes:
>> >
>> > > These patches, along with a few more hacks [1] I didn't include
>> > > in this patchset, allowed me to run arm64 and armv7 version of
>> > > dind image on amd64.
>> > >
>> > > [1] https://github.com/yamt/qemu/tree/linux-user-for-docker
>> >
>> > Might be worth posting those patches next time (even if they have a RFC
>> > or !MERGE in the title for now).
>>
>> ok.
>
> while RFC is mentioned in eg. git format-patch --help,
> i couldn't find what !MERGE is.
> can you provide a reference?

It's usually just an annotation to the subject line of the commit, e.g:

  foo/bar: hacky fix to frobulator (!MERGE)

  rest of commit message

or something like:

  baz/quack: invert the tachyon beam (WIP)

  reason for the fix.

  [AJB: still WIP as this breaks foo]

AFAIK the only subject lines supported by the tooling are the squash:
and fixup: prefixes.

> is there a nice way to express that some patches in a post are meant
> for application and the others are RFC?

Aside from a description in the cover letter not really. The main reason
to include patches that aren't ready for merging is to show where your
work is going so the full context of earlier changes can be seen. Having
an ALL CAPS tag in the subject line is just handy for the maintainer
when scanning what might get cherry picked. Obviously if a patch totally
breaks the build it's not worth including as it just makes review harder
when giving the patches a spin so you should exercise your judgement.

-- 
Alex Bennée