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@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
