On Fri, Jul 22, 2016 at 12:38:44PM -0400, myglc2 wrote:
>ludo@gnu.org (Ludovic Courtès) writes:
>
>> Hi Roel,
>>
>> Roel Janssen <roel@gnu.org> skribis:
>>
>[...]
>>
>>> One thing that really helped me in reducing the time to contribute
>>> changes to the upstream distribution, is to have a good workflow.  I
>>> ended up doing the following:
>>> 1. Make the changes.
>>> 2. Commit the changes.
>>> 3 git format-patch -1 --no-attach
>>> 4. git reset --hard <latest commit on origin/master>
>>> 5. Submit the patch to the mailing list
>>> 6. Wait for response and probably go back to 1.
>>>
>>> I made all of my changes on a GNU Guix git checkout.  So, not writing
>>> package definitions on a separate repository.
>>
>> Do you think it would help to add this as a section in the manual?
>
>This is a great idea!

This reminds me:

https://cdn.meme.am/instances/500x/69604641.jpg


I ended with using topic branches or queues instead, all on top of
master.

wip - not yet finished changes
review - sent to ML and waiting for review
lvm, kernel, ... - branches with some topic changes

cherry-picking from wip to review and sending from there as described
above.

`git pull --rebase' will identify when they have been merged.

S_W