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)

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).

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

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 > >

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

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

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

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)

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

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: >>

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

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,

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

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

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

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

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

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

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

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: [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

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

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

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)

[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

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

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

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

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

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 >>

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

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

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 >