[core-workflow] Questions about the proposed workflows

[Donald Stufft]

> On Dec 14, 2015, at 11:31 AM, Guido van Rossum <guido at python.org> wrote:
> 
> TBH the argument from being able to roll back things doesn't feel very strong at Dropbox. We use a merge process where developers' commits are always squashed into a single commit in master once code review is finished (we have command-line tools for this based on Phabricator's Arcanist). And of course we also have to roll back stuff. But I've never heard of a problem where we had to roll back multiple commits to get back into a reasonable state.

You don’t really need the merge commit if you’re doing squash merges since you have a single atomic unit to roll back which is equal to the final, squashed, commit. It’s difficult to roll back the effect of merging an entire branch with multiple commits if you’re not squash merging but just regular merging if it was a FF merge without merge commits because there is no longer any record that a merge took place at all.

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151214/3e2a27b5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151214/3e2a27b5/attachment-0001.sig>