[core-workflow] Presentation on Rust's GitHub based automation tools

[Brett Cannon]

See
https://mail.python.org/pipermail/core-workflow/2016-February/000469.html and
Ezio's follow-up (and yes, you can help :) .

On Wed, 10 Feb 2016 at 04:29 Maciej Szulik <soltysh at gmail.com> wrote:

> On Tue, Feb 9, 2016 at 7:54 PM, Brett Cannon <brett at python.org> wrote:
> >
> >
> > On Mon, 8 Feb 2016 at 13:11 Maciej Szulik <soltysh at gmail.com> wrote:
> >>
> >> On Mon, Feb 8, 2016 at 5:07 AM, Nick Coghlan <ncoghlan at gmail.com>
> wrote:
> >> > On 7 February 2016 at 20:23, Maciej Szulik <soltysh at gmail.com> wrote:
> >> >> Talking from the position of owning a similar bot in OpenShift, I
> quite
> >> >> certain that it's really hard to have common base. Since these bots
> >> >> address specific project and there are not two exactly the same
> >> >> projects
> >> >> with  exactly the same workflow. I think what Nick meant to show is,
> >> >> what we should target, more or less at least.
> >> >
> >> > It was a combination of a suggestion and a question. The suggestion
> >> > was "Rust's automation UX seems nice, I think it would be desirable to
> >> > target similar capabilities for CPython", the question was "Would it
> >> > be feasible to collaborate on actual automation development?".
> >> >
> >> > It sounds like the pragmatic answer to the latter is "No, the
> >> > additional coordination overhead isn't worth the potential pay-off",
> >> > and I think that's fine - our respective communities can still learn
> >> > from each other when it comes to our definitions of "What does 'good'
> >> > look like?" in workflow design.
> >> >
> >> > Cheers,
> >> > Nick.
> >> >
> >> > --
> >> > Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> >>
> >> I've also reminded one really handy solution described in the
> >> presentation,
> >> which is auto-assigning PR to the owner of certain area. With the list
> we
> >> keep
> >> here: https://docs.python.org/devguide/experts.html we could pretty
> easily
> >> do such mechanism. This will be handy for the devs because assigning
> >> a specific issue will trigger an email notification of such, which in
> turn
> >> is
> >> similar to our noisy in bug tracker. Otherwise the PRs might end up
> >> hanging
> >> there until somebody will do that manually.
> >>
> >> Having said that Brett if you need help with it - I'm here to help you.
> >
> >
> > :) Thanks. Once we have migrated the repositories over we can start
> > discussing enhancements to the workflow like automatic reviewer
> assignment
> > (and I personally have some ideas about PR assignment as well for when
> there
> > isn't an expert).
> >
> > But I don't want to get too distracted by this bonus work when we haven't
> > even started most of the work required to simply match our current
> workflow.
> > It's great that people are excited about making things better and I don't
> > want to squash people's energy to help, but I also don't want to get too
> > distracted by enhancements when we haven't even started a bunch of the
> > minimum work to even move to GitHub, let alone take advantage of what
> bonus
> > features it will bring to the table.
> >
> > My current worry is that we are going to get blocked on Roundup work
> because
> > right now only Ezio and R. David know how that stuff works. Once the CLA
> bot
> > is finished I'm going to shift to helping with that, but it will
> obviously
> > go faster if others can also help with bugs.python.org work because we
> can't
> > switch over until we have a minimum workflow that matches our current
> one.
>
> What's there to be done and how can I help with that, in that case?
>
> Maciej
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160210/2fddc143/attachment.html>