On 02/02/2015 01:11 AM, Nick Coghlan wrote:
On 2 Feb 2015 04:56, "francis" <francismb@email.de <mailto:francismb@email.de>> wrote:
Hi Nick,
On 02/01/2015 08:46 AM, Nick Coghlan wrote: [...]
The updates to PEP 462, which covers proposed changes to the main CPython workflow, were more significant, as I've now rewritten that to depend on PEP 474, and propose replacing the current Rietveld patch review workflow with an updated approach based on Kallithea and Zuul: https://www.python.org/dev/peps/pep-0462/
A small question on: """ Push races would also be a thing of the past - if lots of core developers are approving patches at a sprint, then that just means the queue gets deeper in Zuul, rather than developers getting frustrated trying to merge changes and failing. """ How does the Tool Zuul resolve the case where the patches are not fully compatible. E.g. they touch the same file and some manually merging is needed? (Isn't that a push race? or I'm missing something?)
That's an actual merge conflict, the push races I'm referring to are the ones where there's no conflict, but Mercurial objects to the non-linear history. Zuul takes care of linearising everything and making sure the tests pass before committing the change to the relevant branch.
On this topic, Facebook recently open-sourced a mercurial extension doing server side rebasing to linearise history in simple cases. special flag during push will get your new changes seamlessly rebased on the new head. This however does not run the tests so the Zuul approach is more complete.
PS: Should this be forwarded to python-workflow or is that other list to be considered obsolete?
I withdrew from participating in that list when an individual banned from the core mailing lists and the issue tracker for persistently failing to respect other participants in those communities chose to participate in it despite an explicit request from me that he refrain from doing so (after wasting years trying to coach him into more productive modes of engagement, I now just cut my losses and flat out refuse to work in any environment where he has a significant presence).
Since our moderation practices don't currently include a way to request transferring bans between lists, and I'm reluctant to push for that to change when I have such a clear personal stake in the outcome (it reads like a personal vendetta against the individual concerned), that's the way things are likely to stay unless/until he also gets himself banned from the core workflow list.
Without emitting any judgment on your decision, I'm deeply sad that this list have been "abandoned". -- Pierre-Yves David