Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

On Thu, 7 Jan 2016 at 13:06 francismb wrote: > Hi, > > On 01/05/2016 07:13 PM, Brett Cannon wrote: > > Day 1 summary > > > > > > Decisions made > > --- > > > > - Seems like our current commit ID -> URL service can be updated to > handle > > our transition > > > >

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

Hi, On 01/05/2016 07:13 PM, Brett Cannon wrote: > Day 1 summary > > > Decisions made > --- > > - Seems like our current commit ID -> URL service can be updated to handle > our transition > > > Open issues > --- > - What tools and commands will w

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

On Thu, Jan 7, 2016 at 8:40 PM, Ezio Melotti wrote: > The goal is to generate at least 1 message/email if a review (possibly > comprising several comments) is posted. > If there are no new comments, nothing is posted, but if there are new > comments, a new message will be posted at some point. > W

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

On Thu, Jan 7, 2016 at 12:40 PM, Ezio Melotti wrote: > We can also try to do something smarter by checking e.g. every 15 > minutes and posting the message only if no new messages have been > added in the last 15 minutes (so the reviewer has likely finished > commenting). I like this plan, though

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

On Wed, 6 Jan 2016 at 23:56 Ezio Melotti wrote: > On Wed, Jan 6, 2016 at 8:18 PM, Brett Cannon wrote: > > > > > > On Tue, 5 Jan 2016 at 23:46 Ezio Melotti wrote: > >> ... > >> If you agree, this is what needs to be done: > >> 1) automatically add PRs to b.p.o issues; > > > > > > This is a block

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

On Wed, Jan 6, 2016 at 8:18 PM, Brett Cannon wrote: > > > On Tue, 5 Jan 2016 at 23:46 Ezio Melotti wrote: >> ... >> If you agree, this is what needs to be done: >> 1) automatically add PRs to b.p.o issues; > > > This is a blocker. > >> >> 2) automatically add a message on b.p.o when a review is p

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

In a message of Tue, 05 Jan 2016 12:22:03 +0100, "M.-A. Lemburg" writes: >Given that we want to make it possible to move away from Github >without too much fuzz, wouldn't it be better to have the >PR discussions on b.p.o and Rietvield ? +1 >If we start using Github for this, we'd lose that part o

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

On Tue, 5 Jan 2016 at 23:46 Ezio Melotti wrote: > On Tue, Jan 5, 2016 at 9:18 PM, Brett Cannon wrote: > > > > > > On Tue, 5 Jan 2016 at 10:48 R. David Murray > wrote: > >> > >> On Tue, 05 Jan 2016 17:50:53 +, Brett Cannon > wrote: > >> > If people are that worried, we could do a daily dump

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

On Tue, Jan 5, 2016 at 9:18 PM, Brett Cannon wrote: > > > On Tue, 5 Jan 2016 at 10:48 R. David Murray wrote: >> >> On Tue, 05 Jan 2016 17:50:53 +, Brett Cannon wrote: >> > If people are that worried, we could do a daily dump of the data. But >> > unless we can have all GitHub-related comment

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

2016-01-05 15:13 GMT-03:00 Brett Cannon : > Open issues > --- > - What tools and commands will we use to convert the repos? I will investigate this soon. I don't claim ESR-level experience in repository conversion, but I did migrate most of KDE from SVN to Git (which was one hell o

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

Donald Stufft writes: > > There is CLAHub (https://www.clahub.com/) but I don’t have any idea how good it is, I just know of it’s existence. CLAHub is apparently dying, see https://github.com/clahub/clahub/issues/111. Another option is https://cla-assistant.io/ which already has features that

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

On Jan 05, 2016, at 06:03 PM, Brett Cannon wrote: >If people are that worried about others being so adverse to using GitHub that >they won't even do an anonymous clone from their servers then we can get a >Bitbucket or GitLab clone set up Once the migration settles down, I do plan on hooking up t

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

We can set a commit status that will show red if the user hasn’t signed the CLA (just like if Travis tests failed or so). No need to use a banner or anything. This is a great idea. Almost any automated check we want to run against PRs can be captured as a Travis/CI test that shows up on the PR wit

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

On Tue, 5 Jan 2016 at 14:19 Eric Snow wrote: > On Tue, Jan 5, 2016 at 11:13 AM, Brett Cannon wrote: > > Day 1 summary > > > > > > Decisions made > > --- > > > > Open issues > > --- > > And a couple things that we are punting on: > > * code review

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

On Tue, Jan 5, 2016 at 11:13 AM, Brett Cannon wrote: > Day 1 summary > > > Decisions made > --- > > Open issues > --- And a couple things that we are punting on: * code review tool (if GH proves undesirable) * separate (sub)repos for docs/tutorial

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

On Tue, Jan 5, 2016 at 8:13 PM, Brett Cannon wrote: > Day 1 summary > > > Decisions made > --- > - We will create a python-dev team in the python org and add that team to > all of the relevant repos that get migrated > - We will add a GitHub field to Roundup and th

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

On Tue, 5 Jan 2016 at 12:35 Senthil Kumaran wrote: > Hi Brett, > > On Tue, Jan 5, 2016 at 10:13 AM, Brett Cannon wrote: > >> - We are going to keep all of the cpython history in a single repo > > > Are we not going to have 2.7 as a separate repo? > I believe, this is possible even if we keep cpy

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

On Tue, Jan 5, 2016 at 12:36 PM, Guido van Rossum wrote: > > > Why would you want this? > In general, our changes to 2.7 are separate from 3.x lines. So the pull requests and reviews could be handled separately. We could encourage feature contributions only to cpython (3.x) repo and any maintain

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

On Tue, Jan 5, 2016 at 12:35 PM, Senthil Kumaran wrote: > Are we not going to have 2.7 as a separate repo? > Why would you want this? > I believe, this is possible even if we keep cpython with full history (and > branches). > -- --Guido van Rossum (python.org/~guido)

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

Hi Brett, On Tue, Jan 5, 2016 at 10:13 AM, Brett Cannon wrote: > - We are going to keep all of the cpython history in a single repo Are we not going to have 2.7 as a separate repo? I believe, this is possible even if we keep cpython with full history (and branches). Thanks, Senthil __

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

On Tue, 5 Jan 2016 at 10:48 R. David Murray wrote: > On Tue, 05 Jan 2016 17:50:53 +, Brett Cannon wrote: > > If people are that worried, we could do a daily dump of the data. But > > unless we can have all GitHub-related comments to an issue not trigger an > > email update I don't think that

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

On Tue, 05 Jan 2016 17:50:53 +, Brett Cannon wrote: > If people are that worried, we could do a daily dump of the data. But > unless we can have all GitHub-related comments to an issue not trigger an > email update I don't think that's feasible as it would mean two emails for > every PR commen

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

> On Jan 5, 2016, at 1:03 PM, Brett Cannon wrote: > > > > On Mon, 4 Jan 2016 at 21:54 Ezio Melotti > wrote: > On Tue, Jan 5, 2016 at 2:42 AM, Brett Cannon > wrote: > > So consider this the starting discussion of the PEP that will be the

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

On Tue, 5 Jan 2016 at 10:11 Donald Stufft wrote: > On Jan 5, 2016, at 1:03 PM, Brett Cannon wrote: > > > > On Mon, 4 Jan 2016 at 21:54 Ezio Melotti wrote: > >> On Tue, Jan 5, 2016 at 2:42 AM, Brett Cannon wrote: >> > So consider this the starting discussion of the PEP that will be the >> > hg.

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

Day 1 summary Decisions made --- - We will create a python-dev team in the python org and add that team to all of the relevant repos that get migrated - We will add a GitHub field to Roundup and then write/get a CLA bot that will query Roundup to check if someone h

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

On 05.01.2016 18:50, Brett Cannon wrote: > On Tue, 5 Jan 2016 at 03:22 M.-A. Lemburg wrote: > >> On 05.01.2016 06:53, Ezio Melotti wrote: Or is there some prepackaged service that we can use that will keep track of this which would cause us to not use Roundup (which might be easier

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

On Mon, 4 Jan 2016 at 21:54 Ezio Melotti wrote: > On Tue, Jan 5, 2016 at 2:42 AM, Brett Cannon wrote: > > So consider this the starting discussion of the PEP that will be the > > hg.python.org -> GitHub transition PEP that I will be in charge of. > Once we > > have general agreement on the steps

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

On Tue, 5 Jan 2016 at 03:22 M.-A. Lemburg wrote: > On 05.01.2016 06:53, Ezio Melotti wrote: > >> Or is there some prepackaged service that > >> we can use that will keep track of this which would cause us to not use > >> Roundup (which might be easier, but depending on the service require > >> ev

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

On 05.01.2016 06:53, Ezio Melotti wrote: >> Or is there some prepackaged service that >> we can use that will keep track of this which would cause us to not use >> Roundup (which might be easier, but depending on the service require >> everyone to re-sign)? There's also the issue of supporting peop

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

> On Jan 5, 2016, at 12:53 AM, Ezio Melotti wrote: > >> >> Or is there some prepackaged service that >> we can use that will keep track of this which would cause us to not use >> Roundup (which might be easier, but depending on the service require >> everyone to re-sign)? There's also the issue

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

On Tue, Jan 5, 2016 at 5:18 AM, Nick Coghlan wrote: > On 5 January 2016 at 10:42, Brett Cannon wrote: >> ... >> >> First, we need to decide how we are going to handle adding all the core devs >> to GitHub. Are we simply going to add all of them to the python >> organization, or do we want somethi

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

On Tue, Jan 5, 2016 at 2:42 AM, Brett Cannon wrote: > So consider this the starting discussion of the PEP that will be the > hg.python.org -> GitHub transition PEP that I will be in charge of. Once we > have general agreement on the steps necessary I will start the actual PEP > and check it in, bu

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

> On Jan 4, 2016, at 10:45 PM, Nick Coghlan wrote: > > On 5 January 2016 at 11:08, Donald Stufft wrote: >> >> On Jan 4, 2016, at 7:42 PM, Brett Cannon wrote: >>> We should try to get test coverage wired up as well per CI. I don't know if >>> coveralls.io or some other provider is best, but we

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

On 5 January 2016 at 11:08, Donald Stufft wrote: > > On Jan 4, 2016, at 7:42 PM, Brett Cannon wrote: >> We should try to get test coverage wired up as well per CI. I don't know if >> coveralls.io or some other provider is best, but we should see what is >> available and find out if we can use the

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

On 5 January 2016 at 10:42, Brett Cannon wrote: > So consider this the starting discussion of the PEP that will be the > hg.python.org -> GitHub transition PEP that I will be in charge of. Once we > have general agreement on the steps necessary I will start the actual PEP > and check it in, but I

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

Something else to consider. We’ve long talked about splitting out the stdlib to make it easier for the alternative implementations to import. If some or all of them also switch to git, we could do that pretty easily with git submodules. Not to derail here, but wasn’t there a discussion (perhaps on

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

> On Jan 4, 2016, at 9:42 PM, Barry Warsaw wrote: > > Something else to consider. We've long talked about splitting out the stdlib > to make it easier for the alternative implementations to import. If some or > all of them also switch to git, we could do that pretty easily with git > submodule

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

On Jan 05, 2016, at 12:42 AM, Brett Cannon wrote: >The way I see it, we have 4 repos to move: devinabox, benchmarks, peps, >devguide, and cpython. Arthur: Each core dev converts four repos... Knight: Five repos Arthur: He who converts the repos four... Knight: Five repos Arthur: Five repos may ha

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

> On Jan 4, 2016, at 7:42 PM, Brett Cannon wrote: > > So consider this the starting discussion of the PEP that will be the > hg.python.org -> GitHub transition PEP that I will be > in charge of. Once we have general agreement on the steps necessary I will > start the a

[core-workflow] My initial thoughts on the steps/blockers of the transition

So consider this the starting discussion of the PEP that will be the hg.python.org -> GitHub transition PEP that I will be in charge of. Once we have general agreement on the steps necessary I will start the actual PEP and check it in, but I figure there's no point in have a skeleton PEP if we can'