On 18 March 2015 at 00:03, Brett Cannon <bcan...@gmail.com> wrote: > On Mon, Mar 16, 2015 at 6:06 PM Ezio Melotti <ezio.melo...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
