Re: [core-workflow] We will be moving to GitHub

Dear Cores-Devs, > > [...] And the long-term > plan is to set up a bot that will handle our commit workflow which will > help isolate us from any repository hosting platform we are on and making > moving easier in the future (and short-term people will use the > command-line and that's totally pl

Re: [core-workflow] We will be moving to GitHub

Thank you Brett, Donald, Barry, Nick, Ezio, and all who have worked on core workflow. I believe that moving code review to GitHub will benefit CPython and allow more automated checks and feedback (such as those provided by Travis, codecov, coverage, etc) that will help new contributors as well

Re: [core-workflow] We will be moving to GitHub

On Fri, 1 Jan 2016 at 13:37 R. David Murray wrote: > On Fri, 01 Jan 2016 20:25:11 +, Stefan Krah < > [email protected]> wrote: > > Brett Cannon writes: > > > I don't think this will be a shock to anyone who has followed the > > discussion on this list. The decision is essentially b

Re: [core-workflow] We will be moving to GitHub

I was purposefully trying to avoid having this discussion start until Monday, but since Ezio sort has a deadline for issue-related stuff we can start on that side now (I still have an email planned on Monday to outline the initial steps to moving things over and the very first hurdle to work throug

[core-workflow] I'm going to let Jython know what's happening

I don't know if they are going to ask to come under the python organization or go do their own thing, but I'm going to make sure they know what's going on over here. ___ core-workflow mailing list [email protected] https://mail.python.org/mailman/l

Re: [core-workflow] We will be moving to GitHub

On Sat, 2 Jan 2016 at 07:01 francismb wrote: > Dear Cores-Devs, > > > > > [...] And the long-term > > plan is to set up a bot that will handle our commit workflow which will > > help isolate us from any repository hosting platform we are on and making > > moving easier in the future (and short-te

Re: [core-workflow] We will be moving to GitHub

Brett Cannon writes: > But also realize that this process has been going on for over a year now. I have had multiple conversations at conferences at this point with people who expressed various opinions on the matter and I didn't report those face-to-face conversations either and which are no diff

Re: [core-workflow] We will be moving to GitHub

On Sat, Jan 2, 2016 at 8:45 PM, Brett Cannon wrote: > I was purposefully trying to avoid having this discussion start until > Monday, but since Ezio sort has a deadline for issue-related stuff we can > start on that side now (I still have an email planned on Monday to outline > the initial steps t

Re: [core-workflow] We will be moving to GitHub

> On Jan 2, 2016, at 5:35 PM, Ezio Melotti wrote: > > GitHub should also link to b.p.o issues when an issue number appears > in the PR (I don't know if/how this can be done). By default this isn’t allowed, but I think you could use the web hook based support in Github with a bot that has permi

Re: [core-workflow] We will be moving to GitHub

On Sun, Jan 3, 2016 at 12:35 AM, Ezio Melotti wrote: > On Sat, Jan 2, 2016 at 8:45 PM, Brett Cannon wrote: >> Basically a way to map an issue to a PR (or vice-versa). Probably the >> simplest solution is to allow pasting in a GitHub PR URL or the PR # to make >> the association. The other option

Re: [core-workflow] We will be moving to GitHub

I'm personally disappointed of course, and not at all surprised, especially after Guido's stated preference. But I want to be very clear that I accept the decision and want to express my thanks also to Brett, Nick, Donald, Guido, and everyone else who contributed to the conversation. It heartenin

Re: [core-workflow] We will be moving to GitHub

On Jan 02, 2016, at 06:45 PM, Brett Cannon wrote: >> Some of these things might already be covered by existing PEPs, but I >> don't see them in PEP 507[0] and 481[1] (and I'm getting a bit lost >> among all the competing PEPs and multiple threads across at least a >> couple different MLs :). > >It

Re: [core-workflow] We will be moving to GitHub

First-timer here on this list. Just wanted to chime in briefly on a few things. Basically a way to map an issue to a PR (or vice-versa). Probably the simplest solution is to allow pasting in a GitHub PR URL or the PR # to make the association. The other option is for the bot to accept a command to

Re: [core-workflow] We will be moving to GitHub

First, let me add my thanks for sorting this out! On Jan 2, 2016 11:45, "Brett Cannon" wrote: > Well, "support" as in "allow". We won't be keeping Rietveld around (part of this move is so we can get off of Rietveld). I guess I'd missed this point. In my opinion, code review in Github is unpleas

Re: [core-workflow] We will be moving to GitHub

On Sat, Jan 2, 2016 at 10:41 PM Barry Warsaw [email protected] wrote: It heartening to know that we all care enough about Python, past, present, and future to want to see it succeed not just technically, but socially as well, and decisions about where and how our co

Re: [core-workflow] Longer term idea: consider Rust's homu for CPython merge gating

On Thu, Dec 31, 2015 at 1:21 PM, Brett Cannon wrote: > Thanks for the link! For those that didn't look at the link, Homu is > actually written in Python and not Rust (the website for the project is > what's written in Rust). > > Berker has actually said he is beginning to look into writing a bot

Re: [core-workflow] We will be moving to GitHub

On 3 January 2016 at 13:50, Barry Warsaw wrote: > On Jan 02, 2016, at 06:45 PM, Brett Cannon wrote: > >>> Some of these things might already be covered by existing PEPs, but I >>> don't see them in PEP 507[0] and 481[1] (and I'm getting a bit lost >>> among all the competing PEPs and multiple thre

Re: [core-workflow] We will be moving to GitHub

I'm planning to write a separate PEP. I'll start outlining what I think we need to accomplish and in what order on Monday and that will be the kick-off for the outline of the PEP so we can get a good feel for the work to be done (roughly). On Sat, 2 Jan 2016, 21:40 Nick Coghlan wrote: > On 3 Jan

Re: [core-workflow] Longer term idea: consider Rust's homu for CPython merge gating

On 3 January 2016 at 15:08, Guido van Rossum wrote: > In general I like the idea of a commit queue; we built one at Dropbox which > has been very useful in keeping our master green. Based on this experience, > I note that testing each commit before it's merged limits the rate at which > commits ca