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

[Brett Cannon]

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 has (not) signed the CLA
- For ancillary repos, the merge-of-least-resistance workflow is fine, so
no need to worry about maintaining a linear history
- We are going to keep all of the cpython history in a single repo
- We will have PRs go against master and then we will cherry pick into
bugfix branches
- Misc/ACKS will be kept and we will write code to update it on occasion --
probably at release time -- based on git commit data
- Seems like our current commit ID -> URL service can be updated to handle
our transition


Open issues
---
- What tools and commands will we use to convert the repos?
- How do we want to handle Misc/NEWS?
- What are the exact commands we are going to expect core devs to run
(which will be documented in the devguide)?
- Who to use for CI (although Donald is the only one to speak up and likes
Travis as do I, so this might be decided)?
- Who to use for code coverage (Donald has suggested codecov)?
- Do we want to add GitHub login support for b.p.o to ease in adding
people's GitHub username and to minimize the need for two accounts to
propose a patch that has a corresponding issue?

On Mon, 4 Jan 2016 at 16: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 figure there's no point in have a skeleton PEP
> if we can't agree on the skeleton. :) While I list steps influencing all
> the repos, I want to focus on the ones stopping any repo from moving over
> for now, expanding what we worry about to the cpython repo as we knock
> blockers down until we move everything over and start adding GitHub perks.
>
> The way I see it, we have 4 repos to move: devinabox, benchmarks, peps,
> devguide, and cpython. I also think that's essentially the order we should
> migrate them over. Some things will need to be universally handled before
> we transition a single repo, while other things are only a blocker for some
> of the repos.
>
> Universal blockers
> ==
> There are four blockers that must be resolved before we even consider
> moving a repo over. They can be solved in parallel, but they all need to
> have a selected solution before we can move even the devinabox repo.
>
> 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 something like a specific python-dev gteamroup
> that gets added to all of the relevant repos? Basically I'm not sure how
> picky we want to be about the people who already have organization access
> on GitHub about them implicitly getting access to the cpython repo at the
> end of the day (and the same goes for any of the other repos in the python
> organization). For tracking names, I figure we will create a file in the
> devguide where people can check in their GitHub usernames and I can
> manually add people as people add themselves to the file.
>
> Second, CLA enforcement. As of right now people go to
> https://www.python.org/psf/contrib/contrib-form/, fill in the form, and
> then Ewa gets an email where she manually flips a flag in Roundup. If we
> want to use a web hook to verify someone has signed a CLA then we need to
> decide where the ground truth for CLAs are. Do we want to keep using
> Roundup to manage CLA agreements and thus add a GitHub field in
> bugs.python.org for people's profile and a web hook or bot that will
> signal if someone has the flag flipped on bugs.python.org? 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 people who want to submit code by uploading a patch to
> bugs.python.org but not use GitHub. Either way I don't want to have to
> ask everyone who submits a PR what their bugs.python.org username is and
> then go check that manually.
>
> Third, how do we want to do the repo conversions? We need to choose the
> tool(s) and command(s) that we want to use. There was mention of wanting a
> mapping from hg commit ID to git commit ID. If we have that we could have a
> static bugs.python.org/commit/ page that had the mapping embedded in
> some JavaScript and if  matched then we just forward them to the
> corresponding GitHub commit page, otherwise just blindly forward to GitHub
> and assume the ID is git-only, giving us a stable URL for commit web views.
>
> Fourth, for the 

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

[Brett Cannon]

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.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't agree on the skeleton. :) While I list steps influencing all the
>> > repos, I want to focus on the ones stopping any repo from moving over
>> for
>> > now, expanding what we worry about to the cpython repo as we knock
>> blockers
>> > down until we move everything over and start adding GitHub perks.
>> >
>> > The way I see it, we have 4 repos to move: devinabox, benchmarks, peps,
>> > devguide, and cpython.
>>
>> On top of this, there is also the test repo
>> (https://hg.python.org/test) and all the tracker repos
>> (https://hg.python.org/tracker/).
>> I think it would be useful to port the former since it will provide a
>> place for devs to try things out and experiment (a new test repo could
>> also be created though).
>> It would be nice to port the tracker repos too and be consistent with
>> the others, but it's not a priority.  When we switched to HG they kept
>> being on SVN until I ported them, so I guess the same thing can be
>> done (unless R. David or Martin prefer to stick to HG).
>>
>> > I also think that's essentially the order we should
>> > migrate them over. Some things will need to be universally handled
>> before we
>> > transition a single repo, while other things are only a blocker for
>> some of
>> > the repos.
>> >
>> > Universal blockers
>> > ==
>> > There are four blockers that must be resolved before we even consider
>> moving
>> > a repo over. They can be solved in parallel, but they all need to have a
>> > selected solution before we can move even the devinabox repo.
>> >
>> > 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 something like a specific python-dev
>> gteamroup
>> > that gets added to all of the relevant repos? Basically I'm not sure how
>> > picky we want to be about the people who already have organization
>> access on
>> > GitHub about them implicitly getting access to the cpython repo at the
>> end
>> > of the day (and the same goes for any of the other repos in the python
>> > organization). For tracking names, I figure we will create a file in the
>> > devguide where people can check in their GitHub usernames and I can
>> manually
>> > add people as people add themselves to the file.
>> >
>>
>> I think the current list of core-devs should be converted to a group
>> and given access to the same repos they have access to now (i.e.
>> cpython/devguide/peps and possibly others).  Then additional
>> repo-specific groups can be created in case we want to let specific
>> contributors work on peps or the devguide.
>>
>
> This seems to be the general consensus, so we will create a python-dev
> team under the python org and add the core devs there.
>
>
> Just to expand on this more, GitHub has recently updated their permission
> model more to also allow “outside contributors” to be added to a single
> repository without adding them to a group (Not sure if this would be useful
> for us or not).
>

It will be on the ancillary repos like peps and devguide where we may want
to be more liberal in letting people commit (e.g., maybe we want to add all
PEP authors as outside contributors so that they can maintain their own
PEP).


>
> I imagine the python-dev team would have “Write Access” (See
> https://help.github.com/articles/repository-permission-levels-for-an-organization/)
> unless we think it needs admin access.
>

I think write access is perfect for the vast majority of people. The
question becomes if we want to add anyone specifically with admin access to
help manage repo stuff like web hooks, or if we just bug someone on the
infrastructure team to set it for us.

I do think that some of us -- probably those of us on hgaccounts -- should
be team owners.


>
>
>
>>
>> > Second, CLA enforcement. As of right now people go to
>> > https://www.python.org/psf/contrib/contrib-form/, fill in the form,
>> and then
>> > Ewa gets an email where she manually flips a flag in Roundup. If we
>> want to
>> > use a web hook to verify someone has signed a CLA then we need to decide
>> > where the ground truth for CLAs are. Do we want to keep using Roundup to
>> > manage CLA agreements and thus add a GitHub field in bugs.python.org
>> for
>> > people's profile and a web hook or bot that will signal if someone has
>> the
>> > 

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

[R. David Murray]

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 comment; one from GitHub and one from b.p.o.

We can fairly easily have all github-originated comments not trigger an
email to the nosy list.  We'd just need to add a check for the
originating email address to the nosy reaction detector.  Even nicer
would be to make it a per-user setting (I'd rather get the emails from 
b.p.o. and disable them on github, myself), but that would be a bit more
work.

It would be nice to have *all* of the discussion in one place.

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

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

[Senthil Kumaran]

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

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

[Guido van Rossum]

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

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

[Ezio Melotti]

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 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 comment; one from GitHub and one from b.p.o.
>>
>> We can fairly easily have all github-originated comments not trigger an
>> email to the nosy list.  We'd just need to add a check for the
>> originating email address to the nosy reaction detector.  Even nicer
>> would be to make it a per-user setting (I'd rather get the emails from
>> b.p.o. and disable them on github, myself), but that would be a bit more
>> work.
>>
>> It would be nice to have *all* of the discussion in one place.
>
>
> If someone wants to put the work in to make that happen then that's fine by
> me, but I do consider this a nicety and not a blocker. We haven't had code
> review comments go into b.p.o on Rietveld either so this isn't that far off
> from what we have now, especially if we block the transition on adding a
> link back to the GitHub PR  through a web hook.

I agree it's not a blocker, but a better integration between Rietveld
and b.p.o was often requested (I tried -- and failed -- to tackle the
issue a couple of times).
What I want to avoid is having people on github missing b.p.o
messages, and people on b.p.o missing PRs/reviews on github.  (This
was already happening when people were discussing the patch on
Rietveld, and others were only looking at b.p.o and/or missing the
reviews, both because the email from rietveld ended up in the spam
folder, and because there was no way to know from b.p.o if someone
posted a review.)

I think it's ok to have discussions on b.p.o and reviews on github
(similarly to what we currently do with Rietveld), as long as the
everyone gets notified.  Discussions that are not strictly related to
the code/review shouldn't happen on github.

As for the notifications, I think the best option is:
* when a PR is posted, it's also automatically added to the issue (to
the list of PRs, similar to the list of patches; generates an email
too);
* when a review is posted, a new message with a link is added to the
issue (this is like a regular message, and generates an email too);
* when someone posts a PR/review on github, they will also be added
automatically on the nosy list of the issue on b.p.o (so they will
receive b.p.o messages);
* when a PR/review is posted, people in the issue nosy on b.p.o are
NOT added to the PR nosy list (they already get new PRs/reviews
notifications from b.p.o).

This means that:
* when a PR is posted:
  * the PR author will get a mail from b.p.o confirming that the PR
has been added to the issue if they have a linked account (possibly on
top of any email github might send for creating a PR);
  * people in the issue nosy on b.p.o will get an email that lets them
know a PR has been added;
* when a review is posted:
  * the PR author and the reviewers will get two emails (one from
github and one from b.p.o if they have a linked account) or one (from
github, if they don't);
  * people in the issue nosy will only get one email (from b.p.o, with
a link to the review);
* when a message is posted:
  * the PR author and reviewers will get one email (from b.p.o if they
have a linked account) or zero (if they don't);
  * people in the issue nosy will get one email (from b.p.o);

The "problematic" cases are:
* the PR author and the reviewers will receive two emails for reviews
if they have a linked account;
* the PR author and the reviewers will receive zero emails for b.p.o
messages if they don't have a linked account;

The former can be solved if we add a way to disable review emails from
b.p.o or if github provides one already (or using email filters).  The
latter can't be solved unless they link accounts (I don't think b.p.o
messages should go to github).

FWIW I would personally prefer to get all emails from b.p.o, either
ignoring/filtering duplicated review emails from github, or disabling
them from github if possible.

If you agree, this is what needs to be done:
1) automatically add PRs to b.p.o issues;
2) automatically add a message on b.p.o when a review is posted on github;
3) add a "github username" field to b.p.o users to link accounts;
4) automatically add the PR author (during step 1) and reviewers
(during step 2) to the issue nosy list on b.p.o;
5) add an option to disable review emails (optional);

I would consider all these points except the 5th as blockers.

Best Regards,
Ezio Melotti
___
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: 

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

[Nicolás Alvarez]

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 of a task) :)

However, I will be on vacation and trying to stay away from my email
inbox (except urgent KDE sysadmin matters) from Jan 9th to Jan ~15th.

What's the general timeframe you're thinking for all this? I know
Python is not a corporate project with "deadlines", but I bet nobody
would like "CPython will be in GitHub by early 2017"...

-- 
Nicolás
___
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

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

[Nicolás Alvarez]

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 
CLAHub doesn't, such as posting "You haven't signed the CLA" comments on review 
requests from new contributors.

-- 
Nicolás
Apologies for crappy quoting etc. I'm using Gmane to post this message.
___
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

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

[Nicholas Chammas]

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 with its own
status .

Nick
​

On Tue, Jan 5, 2016 at 5:40 PM Brett Cannon  wrote:

> 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 tool (if GH proves undesirable)
>>
>
> Well, that's implicit if we find GitHub doesn't work for us for code
> review. I don't think it requires explicitly calling it out.
>
>
>> * separate (sub)repos for docs/tutorials--they could have a less
>> restricted workflow than the rest of the cpython repo, a la the
>> devguide
>>
>
> Sure, it can be mentioned.
>
>
>>
>> Both of these can wait until later, though they still deserve mention
>> in the PEP.
>
>
> You really don't like GitHub's review tool, huh? ;)
> ___
> 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
___
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

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

[Eric Snow]

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/tutorials--they could have a less
restricted workflow than the rest of the cpython repo, a la the
devguide

Both of these can wait until later, though they still deserve mention
in the PEP.

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

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

[M.-A. Lemburg]

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 people who want
>> to submit code by uploading a patch to bugs.python.org but not use GitHub.
>> Either way I don't want to have to ask everyone who submits a PR what their
>> bugs.python.org username is and then go check that manually.
>>
> 
> This also brings up another problem.
> Since the discussion about an issue happens on b.p.o and the PRs are
> submitted on GitHub, this means that:
> 1) users with only a GitHub account have to create a b.p.o account if
> they want to comment on the issue (exclusing review comments);
> 2) users with only a b.p.o account have to create a GitHub account if
> they want to review a PR;
> 3) users with both can comment on b.p.o and review on GitHub, but they
> might need to login twice.
> 
> It would be better if users didn't need to create and use two separate 
> accounts.

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 ?

If we start using Github for this, we'd lose that part of the
review history when moving away.

Moving from the SF issue tracker to b.p.o was a major piece of work
(mostly done by Martin von Löwis IIRC) and it's not clear how we
could retrofit those discussions into the b.p.o issue discussions.

Perhaps we could gateway the emails that Github sends for PR
discussions back into b.p.o in some way (the emails contain the
PR number, repo name and Github account name of the sender
in the headers).

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Jan 05 2016)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.com/

___
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

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

[Donald Stufft]

> 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 of supporting people who want
>> to submit code by uploading a patch to bugs.python.org but not use GitHub.
>> Either way I don't want to have to ask everyone who submits a PR what their
>> bugs.python.org username is and then go check that manually.
>> 
> 
> This also brings up another problem.
> Since the discussion about an issue happens on b.p.o and the PRs are
> submitted on GitHub, this means that:
> 1) users with only a GitHub account have to create a b.p.o account if
> they want to comment on the issue (exclusing review comments);
> 2) users with only a b.p.o account have to create a GitHub account if
> they want to review a PR;
> 3) users with both can comment on b.p.o and review on GitHub, but they
> might need to login twice.
> 
> It would be better if users didn't need to create and use two separate 
> accounts.

Can we allow (not mandate) login to b.p.o with a GitHub account? That should 
solve #1 and should sort of solve #3 as well. Ideally it’d allow you to 
associate a Github account with an existing b.p.o account (and doing so should 
also automatically create an association that X on b.p.o is Y on Github).

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

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

[Brett Cannon]

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 cpython with full history (and
> branches).
>

No, we are not going to break 2.7 into a separate repo; everyone else wants
to keep the cpython repo as-is with all branches in a single repo.

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

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

[Berker Peksağ]

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 then write/get a CLA bot that
> will query Roundup to check if someone has (not) signed the CLA
> - For ancillary repos, the merge-of-least-resistance workflow is fine, so no
> need to worry about maintaining a linear history
> - We are going to keep all of the cpython history in a single repo
> - We will have PRs go against master and then we will cherry pick into
> bugfix branches
> - Misc/ACKS will be kept and we will write code to update it on occasion --
> probably at release time -- based on git commit data
> - Seems like our current commit ID -> URL service can be updated to handle
> our transition
>
>
> Open issues
> ---
> - What tools and commands will we use to convert the repos?
> - How do we want to handle Misc/NEWS?
> - What are the exact commands we are going to expect core devs to run (which
> will be documented in the devguide)?

I use the following commands for python.org:

$ git pr NNN

"git pr" is an alias and an equivalent of

$ git fetch upstream pull/NNN/head:pr/NNN
$ git checkout pr/NNN

For example, if I want to review
https://github.com/python/pythondotorg/pull/859, I use "git pr 859".

Run tests, tweak commit message, code style, and commit

$ git commit -m "Update foo bar"

Squash commits

$ git rebase -i HEAD~2

And merge

   $ git checkout master
   $ git merge --ff-only pr/NNN

(--ff-only can be added to .gitconfig)

Backport to 3.5 (the branch name is "release" for python.org)

   $ git checkout 3.5
   $ git cherry-pick `git rev-parse master`

And push to upstream

   $ git push --all upstream

We probably should mention the -u option (or create a new section for
Git configuration and best practices) in the devguide.

> - Who to use for CI (although Donald is the only one to speak up and likes
> Travis as do I, so this might be decided)?

+1 to use Travis as a pre-merge CI. I'd vote for keeping Travis
configuration simple (e.g. use only Linux and GCC, run rstlint in
Doc/)

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

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

[Barry Warsaw]

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 this GitLab mirror,
which was original created as a PEP 507 experiment:

https://gitlab.com/python-devs/python

Cheers,
-Barry


pgp48Yjdq6o9H.pgp
Description: OpenPGP digital signature
___
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

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

[Senthil Kumaran]

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
maintainance improvements from the folks who have 2.7 in production could
be handled in 2.7 repo separately.

Also, I was mapping our hg branches to git repos.

Currently we have 3.4->3.5->default (active)
And 2.7(active)

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