How to submit large series of loosely related changesets in Heptapod

[Raphaël Gomès]

Sorry, the mailing daemon broke because Phabricator used up all disk 
space while fighting for its life. I made sure this wouldn't happen 
again, but only just restarted the daemon, so the email got delayed by a 
few days.

On 6/3/22 20:23, Manuel Jacob wrote:
> I have a branch with Python 3 cleanups 
> (https://foss.heptapod.net/mercurial/mercurial-devel/-/compare/default...py3-cleanups). 
> It consists of more than 30 changesets already and will grow larger.
>
Thanks a lot for this first of all.
> Phabricator has a strong focus on single patches. There, I would 
> submit each patch shortly after creating them. Each can be reviewed 
> and approved individually.
>
> On Heptapod, the focus is more on whole merge request. The Wiki page 
> says that review should be done on single changesets, but it seems 
> like only the whole merge request can be approved and merged (in the UI).
>
Review should always happen at the changeset level (though having the 
full diff can be useful to get a global view of all related changes in 
any given MR, something that IMO was lacking in phab's review UI).

While Heptapod's review tool is not the best at "commit-centric" review, 
the review itself is still very much doable.

> If I create a single merge request when the series is finished (which 
> is whenever I don’t feel to continue), it will be very large and hard 
> to review in one pass. Also, it would mean that I would get feedback 
> on the first changesets later, increasing the chance of getting merge 
> conflicts when changing later changesets (in this case, it hopefully 
> wouldn’t be an issue, because the changes are not very complex).
>
Sure, that's one possibility. As a reviewer I prefer not to get 100 
patches dumped all at once, especially if we can do otherwise.
> If I create a single merge request and continue to add changesets to 
> it, feedback on the first changesets will possibly be earlier, but CI 
> can temporarily break for newer changesets while I keep working on it.
This is something that can be worked around by the reviewer who can take 
an arbitrary subset (most likely always a linear range from the oldest 
changeset), create a separate topic to submit for CI + merging. I think 
I touched about this in the transition email and it was basically "this 
doesn't happen a ton and we may create tooling to help this in the future".
>
> If I create a merge request for each changeset, it will be many and 
> each merge request will contain the unmerged ancestors. Also, I think 
> it would require that each changeset is in its own topic, which 
> complicates matters when working with them locally.
>
This would be quite expensive in terms of churn (and CI), I would advise 
against it.
> I could split them in smaller batches, but it’s not clear how large 
> they should be, and it would combine disadvantages of the two other 
> approaches (although less pronounced).
I think this is the easiest way of doing this. Just send a series, maybe 
no more than 20 patches, and then the next one, etc.
>
> Thoughts?
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel