[core-workflow] bugs.python.org-related GSoC project

[Nick Coghlan]

On 18 March 2015 at 00:03, Brett Cannon <bcannon at gmail.com> wrote:
> On Mon, Mar 16, 2015 at 6:06 PM Ezio Melotti <ezio.melotti at gmail.com> wrote:
>> I'm not sure if Brett was suggesting to do this on the client side
>> (i.e. a tool used by committers on their machines) or something on the
>> b.p.o side since both have been considered and discussed in the past.
>>
>> If it's aimed to committers/contributors (like the one Nick linked)
>> then we have to see if people wants something similar. Personally I
>> find importing a patch from the tracker (hg imp --no-c
>> url_of_the_patch), running the tests (./python -m test), and
>> committing it (hg ci -m "message") trivial, so I would have little use
>> for this tool. I might find it more interesting if it allowed me to
>> post patches to bpo without having to save a .diff and upload it
>> manually, or if it had some kind of interaction with the other tools
>> that we will use.
>
>
> This is what I meant as I was suggesting low-hanging fruit solutions that
> don't require significant tooling. It just seems like the next logical step
> to making patch committal that much simpler and faster.

Right, the idea would be to have a relatively prescriptive extension
where we can say "Don't know Mercurial? Just do this". Gerrit, GitHub
and OpenStack's gitreview offer that kind of experience for using git
- you don't need to learn all of git, just stay within the bounds of
the defined workflow for the project/service.

Learning to use Mercurial independently of the extension would still
be a good long term idea, this would just give us a way to get helpers
into the hands of folks that are either new to Mercurial in general,
or just new to our workflow in particular.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia