[Python-Dev] Workflow improvement PEPs 474 & 462 updated

[Nick Coghlan]

On 2 Feb 2015 04:56, "francis" <francismb at 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.

> And one minor detail. Early on "Current Tools":
> """
> This proposal suggests replacing the use of Rietveld for code review
> with the more full-featured Kallithea-based forge.python.org service
> proposed in PEP 474 .
> """
>
> and then later on "Perceived Benefits":
> """
> the merge queue would allow that developer to focus more of their time
> on reviewing patches and helping the other contributors at the sprint,
> since accepting a patch for inclusion would now be a single click in the
> Rietveld UI, rather [...]
> """
> Isn't "Kallithea UI" meant here?

Good catch - I must have missed that one in the update.

> And +1 for self-hosting on:
> """
> This proposal respects that history by recommending only tools that are
> available for self-hosting as sponsored or PSF funded infrastructure,
> and are also open source Python projects that can be customised to meet
> the needs of the CPython core development team
> """
>
> I like the PEP.
>
>
> 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.

Regards,
Nick.

>
> Regards,
> francis
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150202/8dbe1e18/attachment.html>