FAQ
Hi all,


i we want to move pytest to github what would we do with the
issues? Can someone experiment with migrating the issues to a github
repo (at some user location, not pytest-dev)? A quick search revealed
https://github.com/vbabiy/bitbucket_issue_migration which might help.


best,


holger

Search Discussions

  • Anatoly Bubenkov at Jun 3, 2015 at 2:22 pm
    wow, i didn't expect such a topic from Holger!
    I'll check what's available as well


    On Wed, Jun 3, 2015 at 4:21 PM holger krekel wrote:

    Hi all,

    i we want to move pytest to github what would we do with the
    issues? Can someone experiment with migrating the issues to a github
    repo (at some user location, not pytest-dev)? A quick search revealed
    https://github.com/vbabiy/bitbucket_issue_migration which might help.

    best,

    holger

    --
    about me: http://holgerkrekel.net/about-me/
    contracting: http://merlinux.eu
    _______________________________________________
    pytest-dev mailing list
    pytest-dev at python.org
    https://mail.python.org/mailman/listinfo/pytest-dev
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150603/6b36a847/attachment.html>
  • Holger krekel at Jun 3, 2015 at 2:28 pm

    On Wed, Jun 03, 2015 at 14:22 +0000, Anatoly Bubenkov wrote:
    wow, i didn't expect such a topic from Holger!
    I'll check what's available as well

    I was kind of -0 on the idea so far, maybe +0 now.
    Ronny and Floris also seem to be >=+0 if i get it right.
    So if someone solves the issues issue it might happen :)


    holger

    On Wed, Jun 3, 2015 at 4:21 PM holger krekel wrote:

    Hi all,

    i we want to move pytest to github what would we do with the
    issues? Can someone experiment with migrating the issues to a github
    repo (at some user location, not pytest-dev)? A quick search revealed
    https://github.com/vbabiy/bitbucket_issue_migration which might help.

    best,

    holger

    --
    about me: http://holgerkrekel.net/about-me/
    contracting: http://merlinux.eu
    _______________________________________________
    pytest-dev mailing list
    pytest-dev at python.org
    https://mail.python.org/mailman/listinfo/pytest-dev

    --
    about me: http://holgerkrekel.net/about-me/
    contracting: http://merlinux.eu
  • Bruno Oliveira at Jun 3, 2015 at 2:34 pm

    On Wed, Jun 3, 2015 at 11:22 AM Anatoly Bubenkov bubenkoff at gmail.com wrote:

    wow, i didn't expect such a topic from Holger!
    I'll check what's available as well
    Nice! :)


    Anatoly, let me know if I can help in any way.


    Cheers,



    On Wed, Jun 3, 2015 at 4:21 PM holger krekel wrote:

    Hi all,

    i we want to move pytest to github what would we do with the
    issues? Can someone experiment with migrating the issues to a github
    repo (at some user location, not pytest-dev)? A quick search revealed
    https://github.com/vbabiy/bitbucket_issue_migration which might help.

    best,

    holger

    --
    about me: http://holgerkrekel.net/about-me/
    contracting: http://merlinux.eu
    _______________________________________________
    pytest-dev mailing list
    pytest-dev at python.org
    https://mail.python.org/mailman/listinfo/pytest-dev
    _______________________________________________
    pytest-dev mailing list
    pytest-dev at python.org
    https://mail.python.org/mailman/listinfo/pytest-dev
    ?
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150603/a7116300/attachment.html>
  • Anatoly Bubenkov at Jun 3, 2015 at 4:27 pm
    You are so fast that i'll be late i think
    I'll sit tonight to check the issues on that fork


    On 16:34, Wed, Jun 3, 2015 Bruno Oliveira wrote:

    On Wed, Jun 3, 2015 at 11:22 AM Anatoly Bubenkov bubenkoff at gmail.com
    wrote:

    wow, i didn't expect such a topic from Holger!
    I'll check what's available as well
    Nice! :)

    Anatoly, let me know if I can help in any way.

    Cheers,

    On Wed, Jun 3, 2015 at 4:21 PM holger krekel wrote:

    Hi all,

    i we want to move pytest to github what would we do with the
    issues? Can someone experiment with migrating the issues to a github
    repo (at some user location, not pytest-dev)? A quick search revealed
    https://github.com/vbabiy/bitbucket_issue_migration which might help.

    best,

    holger

    --
    about me: http://holgerkrekel.net/about-me/
    contracting: http://merlinux.eu
    _______________________________________________
    pytest-dev mailing list
    pytest-dev at python.org
    https://mail.python.org/mailman/listinfo/pytest-dev
    _______________________________________________
    pytest-dev mailing list
    pytest-dev at python.org
    https://mail.python.org/mailman/listinfo/pytest-dev
    ?
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150603/ba11ad7f/attachment-0001.html>
  • Florian Bruhin at Jun 3, 2015 at 2:54 pm

    * holger krekel [2015-06-03 14:20:52 +0000]:
    i we want to move pytest to github what would we do with the
    issues? Can someone experiment with migrating the issues to a github
    repo (at some user location, not pytest-dev)? A quick search revealed
    https://github.com/vbabiy/bitbucket_issue_migration which might help.

    Glad to hear!


    I started to play a bit here:
    https://github.com/The-Compiler/pytest-unofficial


    So far, not that much success:


         [...]
         Created: py.test does not cooperate with twisted's trial TestCase [2 comments]
         Created 762 issues
         Traceback (most recent call last):
           File "migrate.py", line 304, in <module>
             push_issue(gh_username, gh_repository, issue, body, comments)
           File "migrate.py", line 266, in push_issue
             format_comment(comment),
           File "migrate.py", line 122, in format_comment
             comment['user'].encode('utf-8')
         UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 91: ordinal not in range(128)


    Time to fix that script then! ;)


    Florian


    --
    http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
        GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
              I love long mails! | http://email.is-not-s.ms/
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 819 bytes
    Desc: not available
    URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150603/c83051bb/attachment-0001.sig>
  • Bruno Oliveira at Jun 3, 2015 at 3:37 pm
    I forked the script and fixed that particular issue:
    https://github.com/nicoddemus/bitbucket_issue_migration/


    Right now I'm hitting another error around 8th issue:


    Created 8 of 762 issues
    Traceback (most recent call last):
       File "migrate.py", line 302, in <module>
         print "Comments", [comment['body'] for comment in comments]
       File "migrate.py", line 265, in push_issue
         gh_repository
       File
    "X:\temp\bitbucket_issue_migration\.env27\lib\site-packages\pygithub3\services\issues\comments.py",
    line 55, in create
         return self._post(request)
       File
    "X:\temp\bitbucket_issue_migration\.env27\lib\site-packages\pygithub3\services\base.py",
    line 139, in _post
         response = self._client.post(request, data=input_data, **kwargs)
       File
    "X:\temp\bitbucket_issue_migration\.env27\lib\site-packages\pygithub3\core\client.py",
    line 89, in post
         response = self.request('post', request, **kwargs)
       File
    "X:\temp\bitbucket_issue_migration\.env27\lib\site-packages\pygithub3\core\client.py",
    line 71, in wrapper
         return func(self, verb, request, **kwargs)
       File
    "X:\temp\bitbucket_issue_migration\.env27\lib\site-packages\pygithub3\core\client.py",
    line 80, in request
         GithubError(response).process()
       File
    "X:\temp\bitbucket_issue_migration\.env27\lib\site-packages\pygithub3\core\errors.py",
    line 36, in process
         self.response.raise_for_status()
       File
    "D:\Shared\dist\12.0-all\requests-2.5.1\lib\site-packages\requests\models.py",
    line 831, in raise_for_status
         raise HTTPError(http_error_msg, response=self)
    requests.exceptions.HTTPError: 403 Client Error: Forbidden


    I will continue investigating, but any help here is welcome.


    Btw, what you guys think about concentrating the issue migration effort in
    a single place? I can add Florian and Anatoly and anyone else interested as
    collaborator of the fork, and we can open a PR to upstream once the script
    is ready.








    On Wed, Jun 3, 2015 at 11:54 AM Florian Bruhin wrote:

    * holger krekel [2015-06-03 14:20:52 +0000]:
    i we want to move pytest to github what would we do with the
    issues? Can someone experiment with migrating the issues to a github
    repo (at some user location, not pytest-dev)? A quick search revealed
    https://github.com/vbabiy/bitbucket_issue_migration which might help.
    Glad to hear!

    I started to play a bit here:
    https://github.com/The-Compiler/pytest-unofficial

    So far, not that much success:

    [...]
    Created: py.test does not cooperate with twisted's trial TestCase [2
    comments]
    Created 762 issues
    Traceback (most recent call last):
    File "migrate.py", line 304, in <module>
    push_issue(gh_username, gh_repository, issue, body, comments)
    File "migrate.py", line 266, in push_issue
    format_comment(comment),
    File "migrate.py", line 122, in format_comment
    comment['user'].encode('utf-8')
    UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position
    91: ordinal not in range(128)

    Time to fix that script then! ;)

    Florian

    --
    http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
    GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
    I love long mails! | http://email.is-not-s.ms/
    _______________________________________________
    pytest-dev mailing list
    pytest-dev at python.org
    https://mail.python.org/mailman/listinfo/pytest-dev
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150603/3420d5e8/attachment.html>
  • Florian Bruhin at Jun 3, 2015 at 3:51 pm

    * Bruno Oliveira [2015-06-03 15:37:24 +0000]:
    I forked the script and fixed that particular issue:
    https://github.com/nicoddemus/bitbucket_issue_migration/

    Thanks! I did almost the same locally, including moving the password
    input up :D

    Right now I'm hitting another error around 8th issue:

    [...]

    I will continue investigating, but any help here is welcome.

    Same here - I printed the response and it's actually this:


         You have triggered an abuse detection mechanism and have been
         temporarily blocked from content creation. Please retry your
         request again later.


         https://developer.github.com/v3#abuse-rate-limits


    Since that documentation says:


         It is not intended for this rate limit to interfere with any
         legitimate use of the API. Your normal rate limits should be the
         only limit you target. Please contact support if your use is
         affected by this rate limit.


    I now contacted GitHub support.


    I bet it's because of that unicode arrow (\u2192, ?) in the comment...

    Btw, what you guys think about concentrating the issue migration effort in
    a single place? I can add Florian and Anatoly and anyone else interested as
    collaborator of the fork, and we can open a PR to upstream once the script
    is ready.

    For the script, or for a playground to do the migration?


    +1 for fixes to the script, but for the playground I'd rather try with
    my own repo, otherwise there'll be a mess if we both try to do
    something ;)


    Could you maybe look at migrating the repo itself and (if needed)
    merge requests? Then I'll continue to look at the issues.


    Florian


    --
    http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
        GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
              I love long mails! | http://email.is-not-s.ms/
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 819 bytes
    Desc: not available
    URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150603/1a2f3a7e/attachment.sig>
  • Bruno Oliveira at Jun 3, 2015 at 3:59 pm
    For the script, or for a playground to do the migration?

    I meant for the script... I agree that everyone should use their own
    playground for testing it. Added you and Anatoly as collaborators, feel
    free to commit any fixes there as you find it.


    Once the script to migrate the issues is stable, we can discuss the next
    steps in detail.


    On Wed, Jun 3, 2015 at 12:51 PM Florian Bruhin wrote:

    * Bruno Oliveira [2015-06-03 15:37:24 +0000]:
    I forked the script and fixed that particular issue:
    https://github.com/nicoddemus/bitbucket_issue_migration/
    Thanks! I did almost the same locally, including moving the password
    input up :D
    Right now I'm hitting another error around 8th issue:

    [...]

    I will continue investigating, but any help here is welcome.
    Same here - I printed the response and it's actually this:

    You have triggered an abuse detection mechanism and have been
    temporarily blocked from content creation. Please retry your
    request again later.

    https://developer.github.com/v3#abuse-rate-limits

    Since that documentation says:

    It is not intended for this rate limit to interfere with any
    legitimate use of the API. Your normal rate limits should be the
    only limit you target. Please contact support if your use is
    affected by this rate limit.

    I now contacted GitHub support.

    I bet it's because of that unicode arrow (\u2192, ?) in the comment...
    Btw, what you guys think about concentrating the issue migration effort in
    a single place? I can add Florian and Anatoly and anyone else interested as
    collaborator of the fork, and we can open a PR to upstream once the script
    is ready.
    For the script, or for a playground to do the migration?

    +1 for fixes to the script, but for the playground I'd rather try with
    my own repo, otherwise there'll be a mess if we both try to do
    something ;)

    Could you maybe look at migrating the repo itself and (if needed)
    merge requests? Then I'll continue to look at the issues.

    Florian

    --
    http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
    GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
    I love long mails! | http://email.is-not-s.ms/
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150603/dfc6b282/attachment.html>
  • Florian Bruhin at Jun 3, 2015 at 4:01 pm

    * Bruno Oliveira [2015-06-03 15:59:17 +0000]:
    For the script, or for a playground to do the migration?
    I meant for the script... I agree that everyone should use their own
    playground for testing it. Added you and Anatoly as collaborators, feel
    free to commit any fixes there as you find it.

    Once the script to migrate the issues is stable, we can discuss the next
    steps in detail.

    Can you please enable issues (so meta!) for the repo?


    Then I suggest to continue discussions there, so people interested in
    it can watch the repo, and everyone else doesn't get annoyed by the
    mails on the ML :)


    Florian


    --
    http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
        GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
              I love long mails! | http://email.is-not-s.ms/
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 819 bytes
    Desc: not available
    URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150603/02187eb7/attachment.sig>
  • Bruno Oliveira at Jun 3, 2015 at 4:12 pm
    Can you please enable issues (so meta!) for the repo?

    Done! :)

    Then I suggest to continue discussions there, so people interested in
    it can watch the repo, and everyone else doesn't get annoyed by the
    mails on the ML :)

    Sure! Everyone interested is welcome to join.


    On Wed, Jun 3, 2015 at 1:01 PM Florian Bruhin wrote:

    * Bruno Oliveira [2015-06-03 15:59:17 +0000]:
    For the script, or for a playground to do the migration?
    I meant for the script... I agree that everyone should use their own
    playground for testing it. Added you and Anatoly as collaborators, feel
    free to commit any fixes there as you find it.

    Once the script to migrate the issues is stable, we can discuss the next
    steps in detail.
    Can you please enable issues (so meta!) for the repo?

    Then I suggest to continue discussions there, so people interested in
    it can watch the repo, and everyone else doesn't get annoyed by the
    mails on the ML :)

    Florian

    --
    http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
    GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
    I love long mails! | http://email.is-not-s.ms/
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150603/ab486478/attachment.html>
  • Holger krekel at Jun 3, 2015 at 6:48 pm

    On Wed, Jun 03, 2015 at 16:12 +0000, Bruno Oliveira wrote:
    Can you please enable issues (so meta!) for the repo? Done! :)
    Then I suggest to continue discussions there, so people interested in
    it can watch the repo, and everyone else doesn't get annoyed by the
    mails on the ML :)
    Sure! Everyone interested is welcome to join.

    For the record, i don't mind discussions here but am also happy
    for discussions to go on in that repo. Thanks all for caring!


    holger

    On Wed, Jun 3, 2015 at 1:01 PM Florian Bruhin wrote:

    * Bruno Oliveira [2015-06-03 15:59:17 +0000]:
    For the script, or for a playground to do the migration?
    I meant for the script... I agree that everyone should use their own
    playground for testing it. Added you and Anatoly as collaborators, feel
    free to commit any fixes there as you find it.

    Once the script to migrate the issues is stable, we can discuss the next
    steps in detail.
    Can you please enable issues (so meta!) for the repo?

    Then I suggest to continue discussions there, so people interested in
    it can watch the repo, and everyone else doesn't get annoyed by the
    mails on the ML :)

    Florian

    --
    http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
    GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
    I love long mails! | http://email.is-not-s.ms/
    _______________________________________________
    pytest-dev mailing list
    pytest-dev at python.org
    https://mail.python.org/mailman/listinfo/pytest-dev



    --
    about me: http://holgerkrekel.net/about-me/
    contracting: http://merlinux.eu
  • Bruno Oliveira at Jun 5, 2015 at 3:06 am
    After a few changes to the script, I have migrated all issues to a
    temporary repository at:
    https://github.com/nicoddemus/pytest-issues-migration.


    Moved issues retain:
    - body
    - creation date
    - comments
    - kind and component (added as labels)


    Issue and comment authors are added to each issue or comment as a note in
    the body, but the issue author will always be the person that ran the
    script (this is a limitation of the GitHub import API). Is this a problem?
    When doing the final migration, which user should we use?


    Any feedback on how we can improve the import process?








    On Wed, Jun 3, 2015 at 3:48 PM holger krekel wrote:

    On Wed, Jun 03, 2015 at 16:12 +0000, Bruno Oliveira wrote:
    Can you please enable issues (so meta!) for the repo? Done! :)
    Then I suggest to continue discussions there, so people interested in
    it can watch the repo, and everyone else doesn't get annoyed by the
    mails on the ML :)
    Sure! Everyone interested is welcome to join.
    For the record, i don't mind discussions here but am also happy
    for discussions to go on in that repo. Thanks all for caring!

    holger
    On Wed, Jun 3, 2015 at 1:01 PM Florian Bruhin wrote:

    * Bruno Oliveira [2015-06-03 15:59:17 +0000]:
    For the script, or for a playground to do the migration?
    I meant for the script... I agree that everyone should use their own
    playground for testing it. Added you and Anatoly as collaborators,
    feel
    free to commit any fixes there as you find it.

    Once the script to migrate the issues is stable, we can discuss the
    next
    steps in detail.
    Can you please enable issues (so meta!) for the repo?

    Then I suggest to continue discussions there, so people interested in
    it can watch the repo, and everyone else doesn't get annoyed by the
    mails on the ML :)

    Florian

    --
    http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
    GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
    I love long mails! | http://email.is-not-s.ms/
    _______________________________________________
    pytest-dev mailing list
    pytest-dev at python.org
    https://mail.python.org/mailman/listinfo/pytest-dev

    --
    about me: http://holgerkrekel.net/about-me/
    contracting: http://merlinux.eu
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150605/e2464f73/attachment.html>
  • Florian Bruhin at Jun 5, 2015 at 4:19 am

    * Bruno Oliveira [2015-06-05 03:06:35 +0000]:
    After a few changes to the script, I have migrated all issues to a
    temporary repository at:
    https://github.com/nicoddemus/pytest-issues-migration.

    Moved issues retain:
    - body
    - creation date
    - comments
    - kind and component (added as labels)

    Awesome, thanks for the great work!

    Issue and comment authors are added to each issue or comment as a note in
    the body, but the issue author will always be the person that ran the
    script (this is a limitation of the GitHub import API). Is this a problem?
    When doing the final migration, which user should we use?

    I suggest creating a new user for the migration so it's immediately
    apparent that's not the real issue author.


    For example, a pytest-dev/pytest-bot/pytest-issue-migration/... user
    with the pytest logo as avatar.

    Any feedback on how we can improve the import process?

    I think the "Bitbucket / originally reported by" footer should be at
    the top (before the issue text) instead - again so it's immediately
    apparent what's going on.


    Also, stuff inside <> seems to be removed?
    See https://github.com/nicoddemus/pytest-issues-migration/issues/6#issuecomment-109143858
    for example.


    Some other ideas which might or might not be worth the effort:


    - Rewrite full links to an issue (as opposed to #nnn identifiers) to
       point to the correct/new location (or to use #nnn instead)


    - Rewrite links to PRs, if PRs will be migrated


    - Rewrite those "-> <<cset ...>>" comments to point at git commits
       (when the repo is migrated) instead of hg changesets).
       (See link above for a [broken] example)


    Florian


    --
    http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
        GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
              I love long mails! | http://email.is-not-s.ms/
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 819 bytes
    Desc: not available
    URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150605/b76bab0e/attachment.sig>
  • Bruno Oliveira at Jun 5, 2015 at 3:33 pm

    On Fri, Jun 5, 2015 at 1:19 AM Florian Bruhin wrote:


    When doing the final migration, which user should we use?
    I suggest creating a new user for the migration so it's immediately
    apparent that's not the real issue author.


    For example, a pytest-dev/pytest-bot/pytest-issue-migration/... user
    with the pytest logo as avatar.

    Yes, that seems like a good solution. :)


    About your other suggestions, I agree with most of them and created an
    issue with your points here:
    https://github.com/nicoddemus/bitbucket_issue_migration/issues/2


    There are only two which I don't think are worth the effort:


    - Porting PRs seems to be tricky, since we would have to port the patches
    as well;
    - Update the changesets that appear in issues/comments: since those
    changesets will be different when we convert from Mercurial to Git, there's
    no easy way to map them;


    If others have any more suggestions, feel free to comment here or at
    https://github.com/nicoddemus/bitbucket_issue_migration/issues/2.


    Cheers,



    I think the "Bitbucket / originally reported by" footer should be at
    the top (before the issue text) instead - again so it's immediately
    apparent what's going on.

    Also, stuff inside <> seems to be removed?
    See
    https://github.com/nicoddemus/pytest-issues-migration/issues/6#issuecomment-109143858
    for example.

    Some other ideas which might or might not be worth the effort:

    - Rewrite full links to an issue (as opposed to #nnn identifiers) to
    point to the correct/new location (or to use #nnn instead)

    - Rewrite links to PRs, if PRs will be migrated

    - Rewrite those "-> <<cset ...>>" comments to point at git commits
    (when the repo is migrated) instead of hg changesets).
    (See link above for a [broken] example)

    Florian

    --
    http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
    GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
    I love long mails! | http://email.is-not-s.ms/
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150605/50e6411a/attachment.html>
  • Bruno Oliveira at Jun 6, 2015 at 3:46 am
    Implemented the last suggestions by Florian, I think issue migration looks
    good now.


    What would be the next steps? I suggest the following list (from the top of
    my head):


    1. Create github.com/pytest-dev/pytest and move issues (better do this
    first so the migrated issues have the same id as the original ones);
    2. Convert pytest Hg repository to Git and upload to GitHub;
    3. Add to bitbucket's README a notice about the move to GitHub, and that
    new issues/PRs should be posted there;
    4. Update all links in the documentation and PyPI;
    5. Update "how to contribute" docs;
    6. Upload new docs to pytest.org;
    7. Ask submitters to re-create PRs at the new repository;
    8. Send an email to all relevant mailing lists about the migration;


    After the migration process is complete, we can start to take advantage of
    GitHub's ecosystem, for example start using Travis for CI, code coverage
    with coveralls.io, etc.


    IMO all this must be done in a short time, because if we start the
    migration process and stall without completing it, links, issues, PRs etc
    might get out of sync, so it it is better to gather a few contributors and
    choose a "Migration Sprint" day to start and finish all the steps required
    for a full migration.


    Cheers,


    On Fri, Jun 5, 2015 at 12:33 PM Bruno Oliveira wrote:

    On Fri, Jun 5, 2015 at 1:19 AM Florian Bruhin wrote:

    When doing the final migration, which user should we use?
    I suggest creating a new user for the migration so it's immediately
    apparent that's not the real issue author.
    For example, a pytest-dev/pytest-bot/pytest-issue-migration/... user
    with the pytest logo as avatar.
    Yes, that seems like a good solution. :)

    About your other suggestions, I agree with most of them and created an
    issue with your points here:
    https://github.com/nicoddemus/bitbucket_issue_migration/issues/2

    There are only two which I don't think are worth the effort:

    - Porting PRs seems to be tricky, since we would have to port the patches
    as well;
    - Update the changesets that appear in issues/comments: since those
    changesets will be different when we convert from Mercurial to Git, there's
    no easy way to map them;

    If others have any more suggestions, feel free to comment here or at
    https://github.com/nicoddemus/bitbucket_issue_migration/issues/2.

    Cheers,

    I think the "Bitbucket / originally reported by" footer should be at
    the top (before the issue text) instead - again so it's immediately
    apparent what's going on.

    Also, stuff inside <> seems to be removed?
    See
    https://github.com/nicoddemus/pytest-issues-migration/issues/6#issuecomment-109143858
    for example.

    Some other ideas which might or might not be worth the effort:

    - Rewrite full links to an issue (as opposed to #nnn identifiers) to
    point to the correct/new location (or to use #nnn instead)

    - Rewrite links to PRs, if PRs will be migrated

    - Rewrite those "-> <<cset ...>>" comments to point at git commits
    (when the repo is migrated) instead of hg changesets).
    (See link above for a [broken] example)

    Florian

    --
    http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
    GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
    I love long mails! | http://email.is-not-s.ms/
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150606/3e5a8aa0/attachment-0001.html>
  • Anatoly Bubenkov at Jun 6, 2015 at 10:15 am
    Sounds like a good plan!
    It's easier to implement it by one person I think and that person is you! :)


    On 05:46, Sat, Jun 6, 2015 Bruno Oliveira wrote:

    Implemented the last suggestions by Florian, I think issue migration looks
    good now.

    What would be the next steps? I suggest the following list (from the top
    of my head):

    1. Create github.com/pytest-dev/pytest and move issues (better do this
    first so the migrated issues have the same id as the original ones);
    2. Convert pytest Hg repository to Git and upload to GitHub;
    3. Add to bitbucket's README a notice about the move to GitHub, and that
    new issues/PRs should be posted there;
    4. Update all links in the documentation and PyPI;
    5. Update "how to contribute" docs;
    6. Upload new docs to pytest.org;
    7. Ask submitters to re-create PRs at the new repository;
    8. Send an email to all relevant mailing lists about the migration;

    After the migration process is complete, we can start to take advantage of
    GitHub's ecosystem, for example start using Travis for CI, code coverage
    with coveralls.io, etc.

    IMO all this must be done in a short time, because if we start the
    migration process and stall without completing it, links, issues, PRs etc
    might get out of sync, so it it is better to gather a few contributors and
    choose a "Migration Sprint" day to start and finish all the steps required
    for a full migration.

    Cheers,
    On Fri, Jun 5, 2015 at 12:33 PM Bruno Oliveira wrote:

    On Fri, Jun 5, 2015 at 1:19 AM Florian Bruhin <me@the-compiler.org>
    wrote:
    When doing the final migration, which user should we use?
    I suggest creating a new user for the migration so it's immediately
    apparent that's not the real issue author.
    For example, a pytest-dev/pytest-bot/pytest-issue-migration/... user
    with the pytest logo as avatar.
    Yes, that seems like a good solution. :)

    About your other suggestions, I agree with most of them and created an
    issue with your points here:
    https://github.com/nicoddemus/bitbucket_issue_migration/issues/2

    There are only two which I don't think are worth the effort:

    - Porting PRs seems to be tricky, since we would have to port the patches
    as well;
    - Update the changesets that appear in issues/comments: since those
    changesets will be different when we convert from Mercurial to Git, there's
    no easy way to map them;

    If others have any more suggestions, feel free to comment here or at
    https://github.com/nicoddemus/bitbucket_issue_migration/issues/2.

    Cheers,

    I think the "Bitbucket / originally reported by" footer should be at
    the top (before the issue text) instead - again so it's immediately
    apparent what's going on.

    Also, stuff inside <> seems to be removed?
    See
    https://github.com/nicoddemus/pytest-issues-migration/issues/6#issuecomment-109143858
    for example.

    Some other ideas which might or might not be worth the effort:

    - Rewrite full links to an issue (as opposed to #nnn identifiers) to
    point to the correct/new location (or to use #nnn instead)

    - Rewrite links to PRs, if PRs will be migrated

    - Rewrite those "-> <<cset ...>>" comments to point at git commits
    (when the repo is migrated) instead of hg changesets).
    (See link above for a [broken] example)

    Florian

    --
    http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
    GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
    I love long mails! | http://email.is-not-s.ms/
    _______________________________________________
    pytest-dev mailing list
    pytest-dev at python.org
    https://mail.python.org/mailman/listinfo/pytest-dev
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150606/165400cc/attachment.html>
  • Bruno Oliveira at Jun 7, 2015 at 4:59 pm
    No problem, if everybody agrees.


    I'm playing with converting the mercurial repository to Git, having used
    the HgGit plugin (http://hg-git.github.io/) and pushed the converted
    repository to https://github.com/nicoddemus/pytest-issues-migration. Seems
    OK to me, but does anyone with more experience want to suggest some other
    approach perhaps?


    I think a good time to do the complete migration would be during the
    weekend when there is not much going on repository and issue wise. How does
    next Saturday (June 13th) sound to everyone?


    On Sat, Jun 6, 2015 at 7:15 AM Anatoly Bubenkov wrote:

    Sounds like a good plan!
    It's easier to implement it by one person I think and that person is you!
    :)
    On 05:46, Sat, Jun 6, 2015 Bruno Oliveira wrote:

    Implemented the last suggestions by Florian, I think issue migration
    looks good now.

    What would be the next steps? I suggest the following list (from the top
    of my head):

    1. Create github.com/pytest-dev/pytest and move issues (better do this
    first so the migrated issues have the same id as the original ones);
    2. Convert pytest Hg repository to Git and upload to GitHub;
    3. Add to bitbucket's README a notice about the move to GitHub, and that
    new issues/PRs should be posted there;
    4. Update all links in the documentation and PyPI;
    5. Update "how to contribute" docs;
    6. Upload new docs to pytest.org;
    7. Ask submitters to re-create PRs at the new repository;
    8. Send an email to all relevant mailing lists about the migration;

    After the migration process is complete, we can start to take advantage
    of GitHub's ecosystem, for example start using Travis for CI, code coverage
    with coveralls.io, etc.

    IMO all this must be done in a short time, because if we start the
    migration process and stall without completing it, links, issues, PRs etc
    might get out of sync, so it it is better to gather a few contributors and
    choose a "Migration Sprint" day to start and finish all the steps required
    for a full migration.

    Cheers,

    On Fri, Jun 5, 2015 at 12:33 PM Bruno Oliveira <nicoddemus@gmail.com>
    wrote:
    On Fri, Jun 5, 2015 at 1:19 AM Florian Bruhin <me@the-compiler.org>
    wrote:
    When doing the final migration, which user should we use?
    I suggest creating a new user for the migration so it's immediately
    apparent that's not the real issue author.
    For example, a pytest-dev/pytest-bot/pytest-issue-migration/... user
    with the pytest logo as avatar.
    Yes, that seems like a good solution. :)

    About your other suggestions, I agree with most of them and created an
    issue with your points here:
    https://github.com/nicoddemus/bitbucket_issue_migration/issues/2

    There are only two which I don't think are worth the effort:

    - Porting PRs seems to be tricky, since we would have to port the
    patches as well;
    - Update the changesets that appear in issues/comments: since those
    changesets will be different when we convert from Mercurial to Git, there's
    no easy way to map them;

    If others have any more suggestions, feel free to comment here or at
    https://github.com/nicoddemus/bitbucket_issue_migration/issues/2.

    Cheers,

    I think the "Bitbucket / originally reported by" footer should be at
    the top (before the issue text) instead - again so it's immediately
    apparent what's going on.

    Also, stuff inside <> seems to be removed?
    See
    https://github.com/nicoddemus/pytest-issues-migration/issues/6#issuecomment-109143858
    for example.

    Some other ideas which might or might not be worth the effort:

    - Rewrite full links to an issue (as opposed to #nnn identifiers) to
    point to the correct/new location (or to use #nnn instead)

    - Rewrite links to PRs, if PRs will be migrated

    - Rewrite those "-> <<cset ...>>" comments to point at git commits
    (when the repo is migrated) instead of hg changesets).
    (See link above for a [broken] example)

    Florian

    --
    http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
    GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
    I love long mails! | http://email.is-not-s.ms/
    _______________________________________________
    pytest-dev mailing list
    pytest-dev at python.org
    https://mail.python.org/mailman/listinfo/pytest-dev
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150607/892883ec/attachment.html>
  • Anatoly Bubenkov at Jun 7, 2015 at 5:40 pm
    Earlier I used gitifyhg to convert
    But if that tool worked, why bother with alternatives


    On 18:59, Sun, Jun 7, 2015 Bruno Oliveira wrote:

    No problem, if everybody agrees.

    I'm playing with converting the mercurial repository to Git, having used
    the HgGit plugin (http://hg-git.github.io/) and pushed the converted
    repository to https://github.com/nicoddemus/pytest-issues-migration.
    Seems OK to me, but does anyone with more experience want to suggest some
    other approach perhaps?

    I think a good time to do the complete migration would be during the
    weekend when there is not much going on repository and issue wise. How does
    next Saturday (June 13th) sound to everyone?
    On Sat, Jun 6, 2015 at 7:15 AM Anatoly Bubenkov wrote:

    Sounds like a good plan!
    It's easier to implement it by one person I think and that person is you!
    :)
    On 05:46, Sat, Jun 6, 2015 Bruno Oliveira wrote:

    Implemented the last suggestions by Florian, I think issue migration
    looks good now.

    What would be the next steps? I suggest the following list (from the top
    of my head):

    1. Create github.com/pytest-dev/pytest and move issues (better do this
    first so the migrated issues have the same id as the original ones);
    2. Convert pytest Hg repository to Git and upload to GitHub;
    3. Add to bitbucket's README a notice about the move to GitHub, and that
    new issues/PRs should be posted there;
    4. Update all links in the documentation and PyPI;
    5. Update "how to contribute" docs;
    6. Upload new docs to pytest.org;
    7. Ask submitters to re-create PRs at the new repository;
    8. Send an email to all relevant mailing lists about the migration;

    After the migration process is complete, we can start to take advantage
    of GitHub's ecosystem, for example start using Travis for CI, code coverage
    with coveralls.io, etc.

    IMO all this must be done in a short time, because if we start the
    migration process and stall without completing it, links, issues, PRs etc
    might get out of sync, so it it is better to gather a few contributors and
    choose a "Migration Sprint" day to start and finish all the steps required
    for a full migration.

    Cheers,

    On Fri, Jun 5, 2015 at 12:33 PM Bruno Oliveira <nicoddemus@gmail.com>
    wrote:
    On Fri, Jun 5, 2015 at 1:19 AM Florian Bruhin <me@the-compiler.org>
    wrote:
    When doing the final migration, which user should we use?
    I suggest creating a new user for the migration so it's immediately
    apparent that's not the real issue author.
    For example, a pytest-dev/pytest-bot/pytest-issue-migration/... user
    with the pytest logo as avatar.
    Yes, that seems like a good solution. :)

    About your other suggestions, I agree with most of them and created an
    issue with your points here:
    https://github.com/nicoddemus/bitbucket_issue_migration/issues/2

    There are only two which I don't think are worth the effort:

    - Porting PRs seems to be tricky, since we would have to port the
    patches as well;
    - Update the changesets that appear in issues/comments: since those
    changesets will be different when we convert from Mercurial to Git, there's
    no easy way to map them;

    If others have any more suggestions, feel free to comment here or at
    https://github.com/nicoddemus/bitbucket_issue_migration/issues/2.

    Cheers,

    I think the "Bitbucket / originally reported by" footer should be at
    the top (before the issue text) instead - again so it's immediately
    apparent what's going on.

    Also, stuff inside <> seems to be removed?
    See
    https://github.com/nicoddemus/pytest-issues-migration/issues/6#issuecomment-109143858
    for example.

    Some other ideas which might or might not be worth the effort:

    - Rewrite full links to an issue (as opposed to #nnn identifiers) to
    point to the correct/new location (or to use #nnn instead)

    - Rewrite links to PRs, if PRs will be migrated

    - Rewrite those "-> <<cset ...>>" comments to point at git commits
    (when the repo is migrated) instead of hg changesets).
    (See link above for a [broken] example)

    Florian

    --
    http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
    GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
    I love long mails! | http://email.is-not-s.ms/
    _______________________________________________
    pytest-dev mailing list
    pytest-dev at python.org
    https://mail.python.org/mailman/listinfo/pytest-dev
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150607/730eab20/attachment-0001.html>
  • Bruno Oliveira at Jun 10, 2015 at 1:07 pm
    Hi guys,


    Just wanted to know if everyone is OK with migrating pytest to GitHub this
    Saturday (June 13th).
    If all agree, I will send an email Saturday when I start the migration
    process (issues + repository), meanwhile no one should commit to BitBucket
    until the process is complete.


    Cheers,






    On Sun, Jun 7, 2015 at 2:40 PM Anatoly Bubenkov wrote:

    Earlier I used gitifyhg to convert
    But if that tool worked, why bother with alternatives
    On 18:59, Sun, Jun 7, 2015 Bruno Oliveira wrote:

    No problem, if everybody agrees.

    I'm playing with converting the mercurial repository to Git, having used
    the HgGit plugin (http://hg-git.github.io/) and pushed the converted
    repository to https://github.com/nicoddemus/pytest-issues-migration.
    Seems OK to me, but does anyone with more experience want to suggest some
    other approach perhaps?

    I think a good time to do the complete migration would be during the
    weekend when there is not much going on repository and issue wise. How does
    next Saturday (June 13th) sound to everyone?

    On Sat, Jun 6, 2015 at 7:15 AM Anatoly Bubenkov <bubenkoff@gmail.com>
    wrote:
    Sounds like a good plan!
    It's easier to implement it by one person I think and that person is
    you! :)
    On 05:46, Sat, Jun 6, 2015 Bruno Oliveira wrote:

    Implemented the last suggestions by Florian, I think issue migration
    looks good now.

    What would be the next steps? I suggest the following list (from the
    top of my head):

    1. Create github.com/pytest-dev/pytest and move issues (better do this
    first so the migrated issues have the same id as the original ones);
    2. Convert pytest Hg repository to Git and upload to GitHub;
    3. Add to bitbucket's README a notice about the move to GitHub, and
    that new issues/PRs should be posted there;
    4. Update all links in the documentation and PyPI;
    5. Update "how to contribute" docs;
    6. Upload new docs to pytest.org;
    7. Ask submitters to re-create PRs at the new repository;
    8. Send an email to all relevant mailing lists about the migration;

    After the migration process is complete, we can start to take advantage
    of GitHub's ecosystem, for example start using Travis for CI, code coverage
    with coveralls.io, etc.

    IMO all this must be done in a short time, because if we start the
    migration process and stall without completing it, links, issues, PRs etc
    might get out of sync, so it it is better to gather a few contributors and
    choose a "Migration Sprint" day to start and finish all the steps required
    for a full migration.

    Cheers,

    On Fri, Jun 5, 2015 at 12:33 PM Bruno Oliveira <nicoddemus@gmail.com>
    wrote:
    On Fri, Jun 5, 2015 at 1:19 AM Florian Bruhin <me@the-compiler.org>
    wrote:
    When doing the final migration, which user should we use?
    I suggest creating a new user for the migration so it's immediately
    apparent that's not the real issue author.
    For example, a pytest-dev/pytest-bot/pytest-issue-migration/... user
    with the pytest logo as avatar.
    Yes, that seems like a good solution. :)

    About your other suggestions, I agree with most of them and created an
    issue with your points here:
    https://github.com/nicoddemus/bitbucket_issue_migration/issues/2

    There are only two which I don't think are worth the effort:

    - Porting PRs seems to be tricky, since we would have to port the
    patches as well;
    - Update the changesets that appear in issues/comments: since those
    changesets will be different when we convert from Mercurial to Git, there's
    no easy way to map them;

    If others have any more suggestions, feel free to comment here or at
    https://github.com/nicoddemus/bitbucket_issue_migration/issues/2.

    Cheers,

    I think the "Bitbucket / originally reported by" footer should be at
    the top (before the issue text) instead - again so it's immediately
    apparent what's going on.

    Also, stuff inside <> seems to be removed?
    See
    https://github.com/nicoddemus/pytest-issues-migration/issues/6#issuecomment-109143858
    for example.

    Some other ideas which might or might not be worth the effort:

    - Rewrite full links to an issue (as opposed to #nnn identifiers) to
    point to the correct/new location (or to use #nnn instead)

    - Rewrite links to PRs, if PRs will be migrated

    - Rewrite those "-> <<cset ...>>" comments to point at git commits
    (when the repo is migrated) instead of hg changesets).
    (See link above for a [broken] example)

    Florian

    --
    http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
    GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
    I love long mails! | http://email.is-not-s.ms/
    _______________________________________________
    pytest-dev mailing list
    pytest-dev at python.org
    https://mail.python.org/mailman/listinfo/pytest-dev
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150610/d5ea9ed2/attachment-0001.html>
  • Anatoly Bubenkov at Jun 10, 2015 at 1:13 pm
    +1


    On Wed, Jun 10, 2015 at 3:07 PM Bruno Oliveira wrote:

    Hi guys,

    Just wanted to know if everyone is OK with migrating pytest to GitHub this
    Saturday (June 13th).
    If all agree, I will send an email Saturday when I start the migration
    process (issues + repository), meanwhile no one should commit to BitBucket
    until the process is complete.

    Cheers,


    On Sun, Jun 7, 2015 at 2:40 PM Anatoly Bubenkov wrote:

    Earlier I used gitifyhg to convert
    But if that tool worked, why bother with alternatives
    On 18:59, Sun, Jun 7, 2015 Bruno Oliveira wrote:

    No problem, if everybody agrees.

    I'm playing with converting the mercurial repository to Git, having used
    the HgGit plugin (http://hg-git.github.io/) and pushed the converted
    repository to https://github.com/nicoddemus/pytest-issues-migration.
    Seems OK to me, but does anyone with more experience want to suggest some
    other approach perhaps?

    I think a good time to do the complete migration would be during the
    weekend when there is not much going on repository and issue wise. How does
    next Saturday (June 13th) sound to everyone?

    On Sat, Jun 6, 2015 at 7:15 AM Anatoly Bubenkov <bubenkoff@gmail.com>
    wrote:
    Sounds like a good plan!
    It's easier to implement it by one person I think and that person is
    you! :)
    On 05:46, Sat, Jun 6, 2015 Bruno Oliveira wrote:

    Implemented the last suggestions by Florian, I think issue migration
    looks good now.

    What would be the next steps? I suggest the following list (from the
    top of my head):

    1. Create github.com/pytest-dev/pytest and move issues (better do
    this first so the migrated issues have the same id as the original ones);
    2. Convert pytest Hg repository to Git and upload to GitHub;
    3. Add to bitbucket's README a notice about the move to GitHub, and
    that new issues/PRs should be posted there;
    4. Update all links in the documentation and PyPI;
    5. Update "how to contribute" docs;
    6. Upload new docs to pytest.org;
    7. Ask submitters to re-create PRs at the new repository;
    8. Send an email to all relevant mailing lists about the migration;

    After the migration process is complete, we can start to take
    advantage of GitHub's ecosystem, for example start using Travis for CI,
    code coverage with coveralls.io, etc.

    IMO all this must be done in a short time, because if we start the
    migration process and stall without completing it, links, issues, PRs etc
    might get out of sync, so it it is better to gather a few contributors and
    choose a "Migration Sprint" day to start and finish all the steps required
    for a full migration.

    Cheers,

    On Fri, Jun 5, 2015 at 12:33 PM Bruno Oliveira <nicoddemus@gmail.com>
    wrote:
    On Fri, Jun 5, 2015 at 1:19 AM Florian Bruhin <me@the-compiler.org>
    wrote:
    When doing the final migration, which user should we use?
    I suggest creating a new user for the migration so it's immediately
    apparent that's not the real issue author.
    For example, a pytest-dev/pytest-bot/pytest-issue-migration/... user
    with the pytest logo as avatar.
    Yes, that seems like a good solution. :)

    About your other suggestions, I agree with most of them and created
    an issue with your points here:
    https://github.com/nicoddemus/bitbucket_issue_migration/issues/2

    There are only two which I don't think are worth the effort:

    - Porting PRs seems to be tricky, since we would have to port the
    patches as well;
    - Update the changesets that appear in issues/comments: since those
    changesets will be different when we convert from Mercurial to Git, there's
    no easy way to map them;

    If others have any more suggestions, feel free to comment here or at
    https://github.com/nicoddemus/bitbucket_issue_migration/issues/2.

    Cheers,

    I think the "Bitbucket / originally reported by" footer should be at
    the top (before the issue text) instead - again so it's immediately
    apparent what's going on.

    Also, stuff inside <> seems to be removed?
    See
    https://github.com/nicoddemus/pytest-issues-migration/issues/6#issuecomment-109143858
    for example.

    Some other ideas which might or might not be worth the effort:

    - Rewrite full links to an issue (as opposed to #nnn identifiers) to
    point to the correct/new location (or to use #nnn instead)

    - Rewrite links to PRs, if PRs will be migrated

    - Rewrite those "-> <<cset ...>>" comments to point at git commits
    (when the repo is migrated) instead of hg changesets).
    (See link above for a [broken] example)

    Florian

    --
    http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
    GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
    I love long mails! | http://email.is-not-s.ms/
    _______________________________________________
    pytest-dev mailing list
    pytest-dev at python.org
    https://mail.python.org/mailman/listinfo/pytest-dev
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150610/1cc17e42/attachment.html>
  • Floris Bruynooghe at Jun 10, 2015 at 11:47 pm

    On 10 June 2015 at 14:07, Bruno Oliveira wrote:
    Hi guys,

    Just wanted to know if everyone is OK with migrating pytest to GitHub this
    Saturday (June 13th).
    If all agree, I will send an email Saturday when I start the migration
    process (issues + repository), meanwhile no one should commit to BitBucket
    until the process is complete.

    What happens to existing pull requests? If we don't merge them before
    Sat we have to convert them to git ourself and re-make the PR?


    I think I'm happy to decline #271 and #292.
    But for #296 I'm preparing a PR at
    https://bitbucket.org/flub/pytest-py35 (because it needed to be
    rebased onto pytest-2.7). I think I'd prefer to merge that before the
    conversion even if not all tests are fixed by Sat (but hopefully they
    will be!). Does that sound reasonable?




    Floris
  • Bruno Oliveira at Jun 11, 2015 at 12:10 am
    Hi Floris,

    What happens to existing pull requests? If we don't merge them before
    Sat we have to convert them to git ourself and re-make the PR?

    Yes, as there are few PRs and there's no automatic way to do migrate them,
    I think that is a reasonable approach. For PRs that; we should ask
    submitters to open new PRs in GitHub after the conversion.

    But for #296 I'm preparing a PR at
    https://bitbucket.org/flub/pytest-py35 (because it needed to be
    rebased onto pytest-2.7). I think I'd prefer to merge that before the
    conversion even if not all tests are fixed by Sat (but hopefully they
    will be!). Does that sound reasonable?

    IMO yes, unless others disagree.


    Cheers,




    On Wed, Jun 10, 2015 at 8:47 PM Floris Bruynooghe wrote:

    On 10 June 2015 at 14:07, Bruno Oliveira wrote:
    Hi guys,

    Just wanted to know if everyone is OK with migrating pytest to GitHub this
    Saturday (June 13th).
    If all agree, I will send an email Saturday when I start the migration
    process (issues + repository), meanwhile no one should commit to BitBucket
    until the process is complete.
    What happens to existing pull requests? If we don't merge them before
    Sat we have to convert them to git ourself and re-make the PR?

    I think I'm happy to decline #271 and #292.
    But for #296 I'm preparing a PR at
    https://bitbucket.org/flub/pytest-py35 (because it needed to be
    rebased onto pytest-2.7). I think I'd prefer to merge that before the
    conversion even if not all tests are fixed by Sat (but hopefully they
    will be!). Does that sound reasonable?


    Floris
    _______________________________________________
    pytest-dev mailing list
    pytest-dev at python.org
    https://mail.python.org/mailman/listinfo/pytest-dev
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150611/c26794a4/attachment.html>
  • Holger krekel at Jun 12, 2015 at 11:26 am
    Hi Bruno,


    was on travel, then ill, initial scan of your work looks great!


    I am not going to be much available during the weekend and would prefer a
    switch date on monday. It's be best to have PRs merged or rejected until
    then.


    As to the migrated issues: i just tried with two random user handles --
    the bitbucket userids map 1:1 to a github one -- so we could add a link
    to the github user (stating "maybe it's this github user: ..." because
    we can't be 100% sure in all cases where the user id exists).


    Also is there a way to, after migration, post to each bitbucket issue
    the link to the corresponding github issue?


    thanks again for the work.


    holger







    On Thu, Jun 11, 2015 at 00:10 +0000, Bruno Oliveira wrote:
    Hi Floris,
    What happens to existing pull requests? If we don't merge them before
    Sat we have to convert them to git ourself and re-make the PR?
    Yes, as there are few PRs and there's no automatic way to do migrate them,
    I think that is a reasonable approach. For PRs that; we should ask
    submitters to open new PRs in GitHub after the conversion.
    But for #296 I'm preparing a PR at
    https://bitbucket.org/flub/pytest-py35 (because it needed to be
    rebased onto pytest-2.7). I think I'd prefer to merge that before the
    conversion even if not all tests are fixed by Sat (but hopefully they
    will be!). Does that sound reasonable?
    IMO yes, unless others disagree.

    Cheers,

    On Wed, Jun 10, 2015 at 8:47 PM Floris Bruynooghe wrote:
    On 10 June 2015 at 14:07, Bruno Oliveira wrote:
    Hi guys,

    Just wanted to know if everyone is OK with migrating pytest to GitHub this
    Saturday (June 13th).
    If all agree, I will send an email Saturday when I start the migration
    process (issues + repository), meanwhile no one should commit to BitBucket
    until the process is complete.
    What happens to existing pull requests? If we don't merge them before
    Sat we have to convert them to git ourself and re-make the PR?

    I think I'm happy to decline #271 and #292.
    But for #296 I'm preparing a PR at
    https://bitbucket.org/flub/pytest-py35 (because it needed to be
    rebased onto pytest-2.7). I think I'd prefer to merge that before the
    conversion even if not all tests are fixed by Sat (but hopefully they
    will be!). Does that sound reasonable?


    Floris
    _______________________________________________
    pytest-dev mailing list
    pytest-dev at python.org
    https://mail.python.org/mailman/listinfo/pytest-dev
    _______________________________________________
    pytest-dev mailing list
    pytest-dev at python.org
    https://mail.python.org/mailman/listinfo/pytest-dev



    --
    about me: http://holgerkrekel.net/about-me/
    contracting: http://merlinux.eu
  • Bruno Oliveira at Jun 12, 2015 at 12:10 pm
    Hi Holger,

    I am not going to be much available during the weekend and would prefer a
    switch date on monday. It's be best to have PRs merged or rejected until
    then.

    I suggested Saturday because usually there's not much commits happening,
    but Monday works for me too.

    As to the migrated issues: i just tried with two random user handles --
    the bitbucket userids map 1:1 to a github one -- so we could add a link
    to the github user (stating "maybe it's this github user: ..." because
    we can't be 100% sure in all cases where the user id exists).

    I thought about this, but was concerned that while there might be two
    identical bitbucket and GitHub user ids, they might not belong to the same
    person.
    In practice I don't think it will be a problem though, so I will add a
    another link to the GitHub user id then.

    Also is there a way to, after migration, post to each bitbucket issue
    the link to the corresponding github issue?

    Yes, good idea, I will implement this as well.

    thanks again for the work.

    No problem, thanks for the feedback.


    Can we set the official migration date to Monday then?


    On Fri, Jun 12, 2015 at 8:26 AM holger krekel wrote:

    Hi Bruno,

    was on travel, then ill, initial scan of your work looks great!

    I am not going to be much available during the weekend and would prefer a
    switch date on monday. It's be best to have PRs merged or rejected until
    then.

    As to the migrated issues: i just tried with two random user handles --
    the bitbucket userids map 1:1 to a github one -- so we could add a link
    to the github user (stating "maybe it's this github user: ..." because
    we can't be 100% sure in all cases where the user id exists).

    Also is there a way to, after migration, post to each bitbucket issue
    the link to the corresponding github issue?

    thanks again for the work.

    holger



    On Thu, Jun 11, 2015 at 00:10 +0000, Bruno Oliveira wrote:
    Hi Floris,
    What happens to existing pull requests? If we don't merge them before
    Sat we have to convert them to git ourself and re-make the PR?
    Yes, as there are few PRs and there's no automatic way to do migrate them,
    I think that is a reasonable approach. For PRs that; we should ask
    submitters to open new PRs in GitHub after the conversion.
    But for #296 I'm preparing a PR at
    https://bitbucket.org/flub/pytest-py35 (because it needed to be
    rebased onto pytest-2.7). I think I'd prefer to merge that before the
    conversion even if not all tests are fixed by Sat (but hopefully they
    will be!). Does that sound reasonable?
    IMO yes, unless others disagree.

    Cheers,

    On Wed, Jun 10, 2015 at 8:47 PM Floris Bruynooghe wrote:
    On 10 June 2015 at 14:07, Bruno Oliveira wrote:
    Hi guys,

    Just wanted to know if everyone is OK with migrating pytest to GitHub this
    Saturday (June 13th).
    If all agree, I will send an email Saturday when I start the
    migration
    process (issues + repository), meanwhile no one should commit to BitBucket
    until the process is complete.
    What happens to existing pull requests? If we don't merge them before
    Sat we have to convert them to git ourself and re-make the PR?

    I think I'm happy to decline #271 and #292.
    But for #296 I'm preparing a PR at
    https://bitbucket.org/flub/pytest-py35 (because it needed to be
    rebased onto pytest-2.7). I think I'd prefer to merge that before the
    conversion even if not all tests are fixed by Sat (but hopefully they
    will be!). Does that sound reasonable?


    Floris
    _______________________________________________
    pytest-dev mailing list
    pytest-dev at python.org
    https://mail.python.org/mailman/listinfo/pytest-dev
    _______________________________________________
    pytest-dev mailing list
    pytest-dev at python.org
    https://mail.python.org/mailman/listinfo/pytest-dev

    --
    about me: http://holgerkrekel.net/about-me/
    contracting: http://merlinux.eu
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150612/abaf1dda/attachment.html>
  • Holger krekel at Jun 13, 2015 at 7:05 am

    On Fri, Jun 12, 2015 at 12:10 +0000, Bruno Oliveira wrote:
    Hi Holger,
    I am not going to be much available during the weekend and would prefer a
    switch date on monday. It's be best to have PRs merged or rejected until
    then.
    I suggested Saturday because usually there's not much commits happening,
    but Monday works for me too.
    As to the migrated issues: i just tried with two random user handles --
    the bitbucket userids map 1:1 to a github one -- so we could add a link
    to the github user (stating "maybe it's this github user: ..." because
    we can't be 100% sure in all cases where the user id exists).
    I thought about this, but was concerned that while there might be two
    identical bitbucket and GitHub user ids, they might not belong to the same
    person.
    In practice I don't think it will be a problem though, so I will add a
    another link to the GitHub user id then.

    yes, i agree that we don't have 100% safety -- therefore my "maybe it's
    this github user" suggestion for a text in the issue.

    Also is there a way to, after migration, post to each bitbucket issue
    the link to the corresponding github issue?
    Yes, good idea, I will implement this as well.

    i guess that this should be a "closing" post so that people
    recognize they need to use github.

    thanks again for the work.
    No problem, thanks for the feedback.

    Can we set the official migration date to Monday then?

    Yes. Can you announce in a top-level post here on the list along
    with the proposed way of what's going to happen?




    holger



    On Fri, Jun 12, 2015 at 8:26 AM holger krekel wrote:

    Hi Bruno,

    was on travel, then ill, initial scan of your work looks great!

    I am not going to be much available during the weekend and would prefer a
    switch date on monday. It's be best to have PRs merged or rejected until
    then.

    As to the migrated issues: i just tried with two random user handles --
    the bitbucket userids map 1:1 to a github one -- so we could add a link
    to the github user (stating "maybe it's this github user: ..." because
    we can't be 100% sure in all cases where the user id exists).

    Also is there a way to, after migration, post to each bitbucket issue
    the link to the corresponding github issue?

    thanks again for the work.

    holger



    On Thu, Jun 11, 2015 at 00:10 +0000, Bruno Oliveira wrote:
    Hi Floris,
    What happens to existing pull requests? If we don't merge them before
    Sat we have to convert them to git ourself and re-make the PR?
    Yes, as there are few PRs and there's no automatic way to do migrate them,
    I think that is a reasonable approach. For PRs that; we should ask
    submitters to open new PRs in GitHub after the conversion.
    But for #296 I'm preparing a PR at
    https://bitbucket.org/flub/pytest-py35 (because it needed to be
    rebased onto pytest-2.7). I think I'd prefer to merge that before the
    conversion even if not all tests are fixed by Sat (but hopefully they
    will be!). Does that sound reasonable?
    IMO yes, unless others disagree.

    Cheers,


    On Wed, Jun 10, 2015 at 8:47 PM Floris Bruynooghe <flub@devork.be>
    wrote:
    On 10 June 2015 at 14:07, Bruno Oliveira wrote:
    Hi guys,

    Just wanted to know if everyone is OK with migrating pytest to GitHub this
    Saturday (June 13th).
    If all agree, I will send an email Saturday when I start the
    migration
    process (issues + repository), meanwhile no one should commit to BitBucket
    until the process is complete.
    What happens to existing pull requests? If we don't merge them before
    Sat we have to convert them to git ourself and re-make the PR?

    I think I'm happy to decline #271 and #292.
    But for #296 I'm preparing a PR at
    https://bitbucket.org/flub/pytest-py35 (because it needed to be
    rebased onto pytest-2.7). I think I'd prefer to merge that before the
    conversion even if not all tests are fixed by Sat (but hopefully they
    will be!). Does that sound reasonable?


    Floris
    _______________________________________________
    pytest-dev mailing list
    pytest-dev at python.org
    https://mail.python.org/mailman/listinfo/pytest-dev
    _______________________________________________
    pytest-dev mailing list
    pytest-dev at python.org
    https://mail.python.org/mailman/listinfo/pytest-dev

    --
    about me: http://holgerkrekel.net/about-me/
    contracting: http://merlinux.eu

    --
    about me: http://holgerkrekel.net/about-me/
    contracting: http://merlinux.eu
  • Bruno Oliveira at Jun 13, 2015 at 4:32 pm

    Yes. Can you announce in a top-level post here on the list along
    with the proposed way of what's going to happen?

    Sure, although I don't think all PRs (currently 6) will be merged/rejected
    until Monday... should we migrate anyway on Monday, or give it a few more
    days to sort the remaining PRs out and do the actual migration, say,
    Wednesday?


    Btw, made another round of migration (issues + repository) at
    https://github.com/pytestbot/pytest-issues-migration if anybody wants to
    take another look.


    Cheers,




    On Sat, Jun 13, 2015 at 4:05 AM holger krekel wrote:

    On Fri, Jun 12, 2015 at 12:10 +0000, Bruno Oliveira wrote:
    Hi Holger,
    I am not going to be much available during the weekend and would
    prefer a
    switch date on monday. It's be best to have PRs merged or rejected
    until
    then.
    I suggested Saturday because usually there's not much commits happening,
    but Monday works for me too.
    As to the migrated issues: i just tried with two random user handles --
    the bitbucket userids map 1:1 to a github one -- so we could add a link
    to the github user (stating "maybe it's this github user: ..." because
    we can't be 100% sure in all cases where the user id exists).
    I thought about this, but was concerned that while there might be two
    identical bitbucket and GitHub user ids, they might not belong to the same
    person.
    In practice I don't think it will be a problem though, so I will add a
    another link to the GitHub user id then.
    yes, i agree that we don't have 100% safety -- therefore my "maybe it's
    this github user" suggestion for a text in the issue.
    Also is there a way to, after migration, post to each bitbucket issue
    the link to the corresponding github issue?
    Yes, good idea, I will implement this as well.
    i guess that this should be a "closing" post so that people
    recognize they need to use github.
    thanks again for the work.
    No problem, thanks for the feedback.

    Can we set the official migration date to Monday then?
    Yes. Can you announce in a top-level post here on the list along
    with the proposed way of what's going to happen?


    holger

    On Fri, Jun 12, 2015 at 8:26 AM holger krekel wrote:

    Hi Bruno,

    was on travel, then ill, initial scan of your work looks great!

    I am not going to be much available during the weekend and would
    prefer a
    switch date on monday. It's be best to have PRs merged or rejected
    until
    then.

    As to the migrated issues: i just tried with two random user handles --
    the bitbucket userids map 1:1 to a github one -- so we could add a link
    to the github user (stating "maybe it's this github user: ..." because
    we can't be 100% sure in all cases where the user id exists).

    Also is there a way to, after migration, post to each bitbucket issue
    the link to the corresponding github issue?

    thanks again for the work.

    holger



    On Thu, Jun 11, 2015 at 00:10 +0000, Bruno Oliveira wrote:
    Hi Floris,
    What happens to existing pull requests? If we don't merge them
    before
    Sat we have to convert them to git ourself and re-make the PR?
    Yes, as there are few PRs and there's no automatic way to do migrate them,
    I think that is a reasonable approach. For PRs that; we should ask
    submitters to open new PRs in GitHub after the conversion.
    But for #296 I'm preparing a PR at
    https://bitbucket.org/flub/pytest-py35 (because it needed to be
    rebased onto pytest-2.7). I think I'd prefer to merge that before
    the
    conversion even if not all tests are fixed by Sat (but hopefully
    they
    will be!). Does that sound reasonable?
    IMO yes, unless others disagree.

    Cheers,


    On Wed, Jun 10, 2015 at 8:47 PM Floris Bruynooghe <flub@devork.be>
    wrote:
    On 10 June 2015 at 14:07, Bruno Oliveira wrote:
    Hi guys,

    Just wanted to know if everyone is OK with migrating pytest to
    GitHub
    this
    Saturday (June 13th).
    If all agree, I will send an email Saturday when I start the
    migration
    process (issues + repository), meanwhile no one should commit to BitBucket
    until the process is complete.
    What happens to existing pull requests? If we don't merge them
    before
    Sat we have to convert them to git ourself and re-make the PR?

    I think I'm happy to decline #271 and #292.
    But for #296 I'm preparing a PR at
    https://bitbucket.org/flub/pytest-py35 (because it needed to be
    rebased onto pytest-2.7). I think I'd prefer to merge that before
    the
    conversion even if not all tests are fixed by Sat (but hopefully
    they
    will be!). Does that sound reasonable?


    Floris
    _______________________________________________
    pytest-dev mailing list
    pytest-dev at python.org
    https://mail.python.org/mailman/listinfo/pytest-dev
    _______________________________________________
    pytest-dev mailing list
    pytest-dev at python.org
    https://mail.python.org/mailman/listinfo/pytest-dev

    --
    about me: http://holgerkrekel.net/about-me/
    contracting: http://merlinux.eu
    --
    about me: http://holgerkrekel.net/about-me/
    contracting: http://merlinux.eu
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150613/8aaac626/attachment.html>
  • Holger krekel at Jun 15, 2015 at 9:35 am

    On Sat, Jun 13, 2015 at 16:32 +0000, Bruno Oliveira wrote:
    Yes. Can you announce in a top-level post here on the list along
    with the proposed way of what's going to happen?
    Sure, although I don't think all PRs (currently 6) will be merged/rejected
    until Monday... should we migrate anyway on Monday, or give it a few more
    days to sort the remaining PRs out and do the actual migration, say,
    Wednesday?

    Btw, made another round of migration (issues + repository) at
    https://github.com/pytestbot/pytest-issues-migration if anybody wants to
    take another look.

    we can go for migration anyway, i am now on IRC.


    holger

    Cheers,

    On Sat, Jun 13, 2015 at 4:05 AM holger krekel wrote:
    On Fri, Jun 12, 2015 at 12:10 +0000, Bruno Oliveira wrote:
    Hi Holger,
    I am not going to be much available during the weekend and would
    prefer a
    switch date on monday. It's be best to have PRs merged or rejected
    until
    then.
    I suggested Saturday because usually there's not much commits happening,
    but Monday works for me too.
    As to the migrated issues: i just tried with two random user handles --
    the bitbucket userids map 1:1 to a github one -- so we could add a link
    to the github user (stating "maybe it's this github user: ..." because
    we can't be 100% sure in all cases where the user id exists).
    I thought about this, but was concerned that while there might be two
    identical bitbucket and GitHub user ids, they might not belong to the same
    person.
    In practice I don't think it will be a problem though, so I will add a
    another link to the GitHub user id then.
    yes, i agree that we don't have 100% safety -- therefore my "maybe it's
    this github user" suggestion for a text in the issue.
    Also is there a way to, after migration, post to each bitbucket issue
    the link to the corresponding github issue?
    Yes, good idea, I will implement this as well.
    i guess that this should be a "closing" post so that people
    recognize they need to use github.
    thanks again for the work.
    No problem, thanks for the feedback.

    Can we set the official migration date to Monday then?
    Yes. Can you announce in a top-level post here on the list along
    with the proposed way of what's going to happen?


    holger

    On Fri, Jun 12, 2015 at 8:26 AM holger krekel <holger@merlinux.eu>
    wrote:
    Hi Bruno,

    was on travel, then ill, initial scan of your work looks great!

    I am not going to be much available during the weekend and would
    prefer a
    switch date on monday. It's be best to have PRs merged or rejected
    until
    then.

    As to the migrated issues: i just tried with two random user handles --
    the bitbucket userids map 1:1 to a github one -- so we could add a link
    to the github user (stating "maybe it's this github user: ..." because
    we can't be 100% sure in all cases where the user id exists).

    Also is there a way to, after migration, post to each bitbucket issue
    the link to the corresponding github issue?

    thanks again for the work.

    holger



    On Thu, Jun 11, 2015 at 00:10 +0000, Bruno Oliveira wrote:
    Hi Floris,
    What happens to existing pull requests? If we don't merge them
    before
    Sat we have to convert them to git ourself and re-make the PR?
    Yes, as there are few PRs and there's no automatic way to do migrate them,
    I think that is a reasonable approach. For PRs that; we should ask
    submitters to open new PRs in GitHub after the conversion.
    But for #296 I'm preparing a PR at
    https://bitbucket.org/flub/pytest-py35 (because it needed to be
    rebased onto pytest-2.7). I think I'd prefer to merge that before
    the
    conversion even if not all tests are fixed by Sat (but hopefully
    they
    will be!). Does that sound reasonable?
    IMO yes, unless others disagree.

    Cheers,


    On Wed, Jun 10, 2015 at 8:47 PM Floris Bruynooghe <flub@devork.be>
    wrote:
    On 10 June 2015 at 14:07, Bruno Oliveira <nicoddemus@gmail.com>
    wrote:
    Hi guys,

    Just wanted to know if everyone is OK with migrating pytest to
    GitHub
    this
    Saturday (June 13th).
    If all agree, I will send an email Saturday when I start the
    migration
    process (issues + repository), meanwhile no one should commit to BitBucket
    until the process is complete.
    What happens to existing pull requests? If we don't merge them
    before
    Sat we have to convert them to git ourself and re-make the PR?

    I think I'm happy to decline #271 and #292.
    But for #296 I'm preparing a PR at
    https://bitbucket.org/flub/pytest-py35 (because it needed to be
    rebased onto pytest-2.7). I think I'd prefer to merge that before
    the
    conversion even if not all tests are fixed by Sat (but hopefully
    they
    will be!). Does that sound reasonable?


    Floris
    _______________________________________________
    pytest-dev mailing list
    pytest-dev at python.org
    https://mail.python.org/mailman/listinfo/pytest-dev
    _______________________________________________
    pytest-dev mailing list
    pytest-dev at python.org
    https://mail.python.org/mailman/listinfo/pytest-dev

    --
    about me: http://holgerkrekel.net/about-me/
    contracting: http://merlinux.eu
    --
    about me: http://holgerkrekel.net/about-me/
    contracting: http://merlinux.eu

    --
    about me: http://holgerkrekel.net/about-me/
    contracting: http://merlinux.eu
  • Anatoly Bubenkov at Jun 16, 2015 at 2:20 am
    after such a success with pytest move, should we start the same process for
    other repos under pytest-dev on bb?


    On Mon, Jun 15, 2015 at 11:35 AM holger krekel wrote:

    On Sat, Jun 13, 2015 at 16:32 +0000, Bruno Oliveira wrote:
    Yes. Can you announce in a top-level post here on the list along
    with the proposed way of what's going to happen?
    Sure, although I don't think all PRs (currently 6) will be
    merged/rejected
    until Monday... should we migrate anyway on Monday, or give it a few more
    days to sort the remaining PRs out and do the actual migration, say,
    Wednesday?

    Btw, made another round of migration (issues + repository) at
    https://github.com/pytestbot/pytest-issues-migration if anybody wants to
    take another look.
    we can go for migration anyway, i am now on IRC.

    holger
    Cheers,

    On Sat, Jun 13, 2015 at 4:05 AM holger krekel wrote:
    On Fri, Jun 12, 2015 at 12:10 +0000, Bruno Oliveira wrote:
    Hi Holger,
    I am not going to be much available during the weekend and would
    prefer a
    switch date on monday. It's be best to have PRs merged or rejected
    until
    then.
    I suggested Saturday because usually there's not much commits
    happening,
    but Monday works for me too.
    As to the migrated issues: i just tried with two random user
    handles --
    the bitbucket userids map 1:1 to a github one -- so we could add a
    link
    to the github user (stating "maybe it's this github user: ..."
    because
    we can't be 100% sure in all cases where the user id exists).
    I thought about this, but was concerned that while there might be two
    identical bitbucket and GitHub user ids, they might not belong to the same
    person.
    In practice I don't think it will be a problem though, so I will add
    a
    another link to the GitHub user id then.
    yes, i agree that we don't have 100% safety -- therefore my "maybe it's
    this github user" suggestion for a text in the issue.
    Also is there a way to, after migration, post to each bitbucket
    issue
    the link to the corresponding github issue?
    Yes, good idea, I will implement this as well.
    i guess that this should be a "closing" post so that people
    recognize they need to use github.
    thanks again for the work.
    No problem, thanks for the feedback.

    Can we set the official migration date to Monday then?
    Yes. Can you announce in a top-level post here on the list along
    with the proposed way of what's going to happen?


    holger

    On Fri, Jun 12, 2015 at 8:26 AM holger krekel <holger@merlinux.eu>
    wrote:
    Hi Bruno,

    was on travel, then ill, initial scan of your work looks great!

    I am not going to be much available during the weekend and would
    prefer a
    switch date on monday. It's be best to have PRs merged or rejected
    until
    then.

    As to the migrated issues: i just tried with two random user
    handles --
    the bitbucket userids map 1:1 to a github one -- so we could add a
    link
    to the github user (stating "maybe it's this github user: ..."
    because
    we can't be 100% sure in all cases where the user id exists).

    Also is there a way to, after migration, post to each bitbucket
    issue
    the link to the corresponding github issue?

    thanks again for the work.

    holger



    On Thu, Jun 11, 2015 at 00:10 +0000, Bruno Oliveira wrote:
    Hi Floris,
    What happens to existing pull requests? If we don't merge them
    before
    Sat we have to convert them to git ourself and re-make the PR?
    Yes, as there are few PRs and there's no automatic way to do
    migrate
    them,
    I think that is a reasonable approach. For PRs that; we should
    ask
    submitters to open new PRs in GitHub after the conversion.
    But for #296 I'm preparing a PR at
    https://bitbucket.org/flub/pytest-py35 (because it needed to
    be
    rebased onto pytest-2.7). I think I'd prefer to merge that
    before
    the
    conversion even if not all tests are fixed by Sat (but
    hopefully
    they
    will be!). Does that sound reasonable?
    IMO yes, unless others disagree.

    Cheers,


    On Wed, Jun 10, 2015 at 8:47 PM Floris Bruynooghe <
    flub at devork.be>
    wrote:
    On 10 June 2015 at 14:07, Bruno Oliveira <nicoddemus at gmail.com
    wrote:
    Hi guys,

    Just wanted to know if everyone is OK with migrating pytest
    to
    GitHub
    this
    Saturday (June 13th).
    If all agree, I will send an email Saturday when I start the
    migration
    process (issues + repository), meanwhile no one should
    commit to
    BitBucket
    until the process is complete.
    What happens to existing pull requests? If we don't merge them
    before
    Sat we have to convert them to git ourself and re-make the PR?

    I think I'm happy to decline #271 and #292.
    But for #296 I'm preparing a PR at
    https://bitbucket.org/flub/pytest-py35 (because it needed to
    be
    rebased onto pytest-2.7). I think I'd prefer to merge that
    before
    the
    conversion even if not all tests are fixed by Sat (but
    hopefully
    they
    will be!). Does that sound reasonable?


    Floris
    _______________________________________________
    pytest-dev mailing list
    pytest-dev at python.org
    https://mail.python.org/mailman/listinfo/pytest-dev
    _______________________________________________
    pytest-dev mailing list
    pytest-dev at python.org
    https://mail.python.org/mailman/listinfo/pytest-dev

    --
    about me: http://holgerkrekel.net/about-me/
    contracting: http://merlinux.eu
    --
    about me: http://holgerkrekel.net/about-me/
    contracting: http://merlinux.eu
    --
    about me: http://holgerkrekel.net/about-me/
    contracting: http://merlinux.eu
    _______________________________________________
    pytest-dev mailing list
    pytest-dev at python.org
    https://mail.python.org/mailman/listinfo/pytest-dev
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150616/78321482/attachment-0001.html>
  • Floris Bruynooghe at Jun 23, 2015 at 12:54 pm

    On 16 June 2015 at 03:20, Anatoly Bubenkov wrote:
    after such a success with pytest move, should we start the same process for
    other repos under pytest-dev on bb?

    Not sure if anyone saw my tweet, but I noticed (sadly too late!) that
    the git repo seems to be ~50Mb to clone instead of ~20Mb for the hg
    one. Is there anything that can still be done about this? And is
    there a way to avoid this for any other repo we might migrate?
  • Anatoly Bubenkov at Jun 23, 2015 at 12:57 pm
    but it's not neccessary (or most likely not) because of the problematic
    migration
    the way git and hg store changes is still different, git always store full
    file contents on any change to it from revision to revision, while hg i
    believe uses some periodic snapshotting mechanism, so it does full copy
    after several incremental diffs


    On Tue, Jun 23, 2015 at 2:54 PM Floris Bruynooghe wrote:

    On 16 June 2015 at 03:20, Anatoly Bubenkov wrote:
    after such a success with pytest move, should we start the same process for
    other repos under pytest-dev on bb?
    Not sure if anyone saw my tweet, but I noticed (sadly too late!) that
    the git repo seems to be ~50Mb to clone instead of ~20Mb for the hg
    one. Is there anything that can still be done about this? And is
    there a way to avoid this for any other repo we might migrate?
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150623/85f4591c/attachment.html>
  • Florian Bruhin at Jun 23, 2015 at 1:05 pm

    * Floris Bruynooghe [2015-06-23 13:54:09 +0100]:
    On 16 June 2015 at 03:20, Anatoly Bubenkov wrote:
    after such a success with pytest move, should we start the same process for
    other repos under pytest-dev on bb?
    Not sure if anyone saw my tweet, but I noticed (sadly too late!) that
    the git repo seems to be ~50Mb to clone instead of ~20Mb for the hg
    one. Is there anything that can still be done about this? And is
    there a way to avoid this for any other repo we might migrate?

    It seems git calculated (because of the import?) very inefficient
    deltas beetween the commits.


    After doing a git gc --aggressive the repo shrinks from 55 MB to
    9.2 MB for me.


    So for future migrations it might make sense to do that in the
    converted git repo before pushing.


    I contacted GitHub support to ask if they can do that on the repo.


    Florian


    --
    http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
        GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
              I love long mails! | http://email.is-not-s.ms/
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 819 bytes
    Desc: not available
    URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150623/c76e497d/attachment.sig>
  • Anatoly Bubenkov at Jun 23, 2015 at 1:46 pm
    nice catch!


    On Tue, Jun 23, 2015 at 3:06 PM Florian Bruhin wrote:

    * Floris Bruynooghe [2015-06-23 13:54:09 +0100]:
    On 16 June 2015 at 03:20, Anatoly Bubenkov wrote:
    after such a success with pytest move, should we start the same
    process for
    other repos under pytest-dev on bb?
    Not sure if anyone saw my tweet, but I noticed (sadly too late!) that
    the git repo seems to be ~50Mb to clone instead of ~20Mb for the hg
    one. Is there anything that can still be done about this? And is
    there a way to avoid this for any other repo we might migrate?
    It seems git calculated (because of the import?) very inefficient
    deltas beetween the commits.

    After doing a git gc --aggressive the repo shrinks from 55 MB to
    9.2 MB for me.

    So for future migrations it might make sense to do that in the
    converted git repo before pushing.

    I contacted GitHub support to ask if they can do that on the repo.

    Florian

    --
    http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
    GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
    I love long mails! | http://email.is-not-s.ms/
    _______________________________________________
    pytest-dev mailing list
    pytest-dev at python.org
    https://mail.python.org/mailman/listinfo/pytest-dev
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150623/c759419a/attachment.html>
  • Florian Bruhin at Jun 24, 2015 at 8:01 am

    * Florian Bruhin [2015-06-23 15:05:51 +0200]:
    * Floris Bruynooghe [2015-06-23 13:54:09 +0100]:
    On 16 June 2015 at 03:20, Anatoly Bubenkov wrote:
    after such a success with pytest move, should we start the same process for
    other repos under pytest-dev on bb?
    Not sure if anyone saw my tweet, but I noticed (sadly too late!) that
    the git repo seems to be ~50Mb to clone instead of ~20Mb for the hg
    one. Is there anything that can still be done about this? And is
    there a way to avoid this for any other repo we might migrate?
    It seems git calculated (because of the import?) very inefficient
    deltas beetween the commits.

    After doing a git gc --aggressive the repo shrinks from 55 MB to
    9.2 MB for me.

    So for future migrations it might make sense to do that in the
    converted git repo before pushing.

    I contacted GitHub support to ask if they can do that on the repo.

    They now did run it, and the download is around 5.7 MB now :)


    Definitely much better - thanks for bringing it up!


    Florian


    --
    http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
        GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
              I love long mails! | http://email.is-not-s.ms/
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 819 bytes
    Desc: not available
    URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150624/05c9df1a/attachment.sig>
  • Floris Bruynooghe at Jun 25, 2015 at 8:53 am

    On 24 June 2015 at 09:01, Florian Bruhin wrote:
    * Florian Bruhin [2015-06-23 15:05:51 +0200]:
    After doing a git gc --aggressive the repo shrinks from 55 MB to
    9.2 MB for me.

    So for future migrations it might make sense to do that in the
    converted git repo before pushing.

    I contacted GitHub support to ask if they can do that on the repo.
    They now did run it, and the download is around 5.7 MB now :)

    Nice! Thanks for looking into this.


    Floris
  • Florian Schulze at Jun 25, 2015 at 9:13 am

    On 25 Jun 2015, at 10:53, Floris Bruynooghe wrote:
    On 24 June 2015 at 09:01, Florian Bruhin wrote:
    * Florian Bruhin [2015-06-23 15:05:51 +0200]:
    After doing a git gc --aggressive the repo shrinks from 55 MB to
    9.2 MB for me.

    So for future migrations it might make sense to do that in the
    converted git repo before pushing.

    I contacted GitHub support to ask if they can do that on the repo.
    They now did run it, and the download is around 5.7 MB now :)
    Nice! Thanks for looking into this.

    I did some experiments on some of my repositories. I had a 800MB
    repository that shrank to 220MB. You have to be careful though. By
    default the repacking has no memory limit and uses as many threads as
    you have cpu cores. My poor server with 16GB Ram and 8 cores used 20GB
    Swap extensively :) On my laptop the process died at first. You can set
    "git config pack.threads 1" and "git config pack.windowMemory 1g" in
    your repository before you run git gc to avoid that issue. The whole
    process can take a pretty long time depending on your repository.


    In general it seems like this is only needed as a final step after a
    migration from another version control system or if you have a lot of
    constant changes in the same files in each commit (I backup database
    dumps with git to keep some history).


    Regards,
    Florian Schulze
  • Petr Viktorin at Jun 25, 2015 at 9:23 am

    On Thu, Jun 25, 2015 at 11:13 AM, Florian Schulze wrote:
    On 25 Jun 2015, at 10:53, Floris Bruynooghe wrote:
    On 24 June 2015 at 09:01, Florian Bruhin wrote:

    * Florian Bruhin [2015-06-23 15:05:51 +0200]:
    After doing a git gc --aggressive the repo shrinks from 55 MB to
    9.2 MB for me.

    So for future migrations it might make sense to do that in the
    converted git repo before pushing.

    I contacted GitHub support to ask if they can do that on the repo.

    They now did run it, and the download is around 5.7 MB now :)

    Nice! Thanks for looking into this.

    I did some experiments on some of my repositories. I had a 800MB repository
    that shrank to 220MB. You have to be careful though. By default the
    repacking has no memory limit and uses as many threads as you have cpu
    cores. My poor server with 16GB Ram and 8 cores used 20GB Swap extensively
    :) On my laptop the process died at first. You can set "git config
    pack.threads 1" and "git config pack.windowMemory 1g" in your repository
    before you run git gc to avoid that issue. The whole process can take a
    pretty long time depending on your repository.

    In general it seems like this is only needed as a final step after a
    migration from another version control system

    Exactly.

    or if you have a lot of
    constant changes in the same files in each commit (I backup database dumps
    with git to keep some history).

    Here's a mail with lots of details, including a better command to use
    than git gc --aggressive:
    https://gcc.gnu.org/ml/gcc/2007-12/msg00165.html

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppytest-dev @
categoriespython
postedJun 3, '15 at 2:20p
activeJun 25, '15 at 9:23a
posts37
users7
websitepython.org

People

Translate

site design / logo © 2018 Grokbase