My comments are interspersed with yours, On 6/2/20 12:57 am, Armin Rigo wrote:

Hi Matti,

Thank you for all the organizational work!

On Wed, 5 Feb 2020 at 10:59, Matti Picus <matti.picus@gmail.com> wrote:

...

- changes our default workflow to "Publishing is restricted to project masters" (I think that means only project masters can push/merge to published branches, but am not sure about the terminology), however we could override that

-1 (who is a project master? do we need the distinction between two levels of membership at all for anything technical?)

...

- disallows personal forks on the instance

-1 (any reason why?)

This is a Octobus decision, so maybe Georges can chime in. My understanding is that because the heptapod offering is on a trial basis, they do not want to open up the possibility for random individuals to open "groups" on the instance. In order to fork a repo, you need a personal "group" as the target. This means that all contributions must be done on the pypy/pypy repo. Their workflow for drive-by contributions is to allow any random user (who logs in via atlassian, github, or heptapos) to push a branch (or topic branch) to the pypy/pypy repo, but only authorized users (they call them "project masters" can merge ("publish") from those branches to the main development branches. We could override this, as explained on the workflow page.

...

- decide which repos to abandon. On the issue above I proposed transferring only a subset of our bitbucket repos, please make sure your favorite is included I suppose I'm +0.5 on dropping the old and unused repos. We still have them around anyway in the sense that any one of us with a copy can re-publish them somewhere at any point. (See also below.)

...

- block changes to the active branches (default, py3.6, py3.7 of pypy, and the HEAD branch of the other repos); any new contributions will have to be done via the heptapod instance So you mean, we would still be allowed to push into the various repos on bitbucket as long as it is not on these main branches? Unsure why.

In order to block changes you need to navigate the UI and disallow each branch separately. It is simply too much work. This is all temporary, on May 31 those repos dissapear.

...

- what to do about downloads? It is not clear that the gitlab instance has a place for artifacts. Assume we find a solution, how far back do we want to keep versions? Would it be possible to just keep this on bitbucket and point to it? I understand the idea of stopping all mercurial services, but a priori they won't delete everything else too? If they do, maybe we just need a hack like convert the pypy repo to git on bitbucket (and then never use it). Same for the wiki. And for all our many-years-old dead repos---we can convert them in-place to git if that means they can stay there.

Of course all this is assuming we're fine with keeping a few historical things on bitbucket. If you decide you'd prefer to have nothing more to do with bitbucket soon and they should die instead of continuing to get however little publicity we'd continue to give them by doing that, then I would understand too.

In order to stay on bitbucket, we would have to - reame pypy/pypy to pypy/pypy_hg - create a new pypy/pypy using a git repo - transfer the downloads and wiki to the new repo As May 31 gets closer, we will have to decide what is easier: these steps or something else. I am personally done with bitbucket/atlassian. Hosting the downloads should be simple, if we had the bandwidth we could do it on the buildbot master. Perhaps we could ask the PSF if we can upload them to www.pypy.org/downloads/files. Hosting the wiki is a bit more complicated. Perhaps since we never get outside edits anyway we could just incorporate it into the pypy.org website as static pages.

A bientôt,

Armin.

Matti

On 6. Feb 2020, at 07:55, Michał Górny <mgorny@gentoo.org> wrote:

Finally, we're living in times where people start caring about their personal data. Even if it's not explicitly personal, people have their doubts about registering on yet another site that's likely going to track them in ways unimaginable.

In as far as tracking is concerned, their data is way safer with Heptapod as compared to Microsoft ;-) Sent from my iPad

On 6. Feb 2020, at 07:24, Matti Picus <matti.picus@gmail.com> wrote:

I am personally done with bitbucket/atlassian. Hosting the downloads should be simple, if we had the bandwidth we could do it on the buildbot master. Perhaps we could ask the PSF if we can upload them to www.pypy.org/downloads/files. Hosting the wiki is a bit more complicated. Perhaps since we never get outside edits anyway we could just incorporate it into the pypy.org website as static pages.

In as far as downloads are concerned, you could try to apply for an account on the OSU OSL mirroring service - they have been hosting downloads for Midnight Commander for almost for a decade by now, and we’ve been very happy with their service. You just scp stuff in your personal directory and trigger a mirroring script per ssh - it gets propagated to the mirrors and there you go - excellent speed, safe storage. Sent from my iPad

Hi there, I'm Heptapod main maintainer. On 2/6/20 7:23 AM, Matti Picus wrote:

...

...

    - disallows personal forks on the instance -1  (any reason why?)

This is a Octobus decision, so maybe Georges can chime in. Yes, I've just subscribed to that effect. I'll try and answer the different concerns separately. My understanding is that because the heptapod offering is on a trial basis, they do not want to open up the possibility for random individuals to open "groups" on the instance. In order to fork a repo, you need a personal "group" as the target. This means that all contributions must be done on the pypy/pypy repo.

This is not completely exact. There are two different aspects to it - Personal forks are just not implemented in Heptapod (the software) yet [1]. I've also written a bit in the FAQ [2] about that. As a side note, it's more complicated to implement properly forks and merge requests from them than other lacking features. - It is true that we don't want to make foss.heptapod.net a space where anybody can create repositories, because we don't have infinite capacity (but we hope we can grow) nor enough work force to watch for illegal content at the scale that implies. But that shouldn't apply to personal forks once we have them.

Their workflow for drive-by contributions is to allow any random user (who logs in via atlassian, github, or heptapos) to push a branch (or topic branch) to the pypy/pypy repo, but only authorized users (they call them "project masters" can merge ("publish") from those branches to the main development branches. We could override this, as explained on the workflow page.

First I should say that "Master" is standard GitLab terminology in the version we're based upon, but has been renamed to "Maintainer" in later versions. It means you have all rights on the repository, except for the like of removal and transfer [3] We also plan to introduce an intermediate role, that could be labelled "Publisher". All of this is indeed backed by the "phases" concept in Mercurial, in which changesets can be "draft" (amendable) or "public" (set in stone) and the fact that topics are additional metadata for draft changesets only. In Heptapod, by default, we enforce that conversely all drafts must have topics. So, the default Heptapod workflow is to grant the Contributor role to people that wish to contribute – they can push topics and submit merge requests – whereas full commit rights translate in the Master role. This is explained and motivated in more detail in the FAQ [4] and in the Octobus blog post [5]. An important implication of all this is that it makes activating the evolve extension [6] almost necessary in practice. It's not meant to be mandatory by itself, see "Mutability and Evolution"  in [5], but once a draft changeset has been amended you'd get surprising warnings if you don't have evolve. Note also that open Bitbucket pull requests are imported as topics [7], and that involves amendments. To conclude, we know that the picture is not perfect and that we could make the transition easier and clearer. We're working on improving all of that, but we have lots of things to do, and we need actual user feedback - such as yours - to prioritize them properly. We're listening. Best, PS: I'm considering coming to the next PyPy sprint in Switzerland. [1] https://foss.heptapod.net/heptapod/heptapod/issues/24 [2] https://heptapod.net/pages/faq.html#forks [3] https://docs.gitlab.com/ce/user/permissions.html [4] https://heptapod.net/pages/faq.html#workflow [5] https://octobus.net/blog/2019-09-04-heptapod-workflow.html [6] https://pypi.org/project/hg-evolve/ and https://www.mercurial-scm.org/doc/evolution/user-guide.html [7] https://foss.heptapod.net/heptapod/heptapod/issues/106 -- Georges Racinet https://octobus.net, https://heptapod.net GPG: BF5456F4DC625443849B6E58EE20CA44EF691D39, sur serveurs publics

My comments are interspersed with yours, On 6/2/20 12:57 am, Armin Rigo wrote:

Hi Matti,

Thank you for all the organizational work!

On Wed, 5 Feb 2020 at 10:59, Matti Picus <matti.picus@gmail.com> wrote:

...

- changes our default workflow to "Publishing is restricted to project masters" (I think that means only project masters can push/merge to published branches, but am not sure about the terminology), however we could override that

-1 (who is a project master? do we need the distinction between two levels of membership at all for anything technical?)

...

- disallows personal forks on the instance

-1 (any reason why?)

This is a Octobus decision, so maybe Georges can chime in. My understanding is that because the heptapod offering is on a trial basis, they do not want to open up the possibility for random individuals to open "groups" on the instance. In order to fork a repo, you need a personal "group" as the target. This means that all contributions must be done on the pypy/pypy repo. Their workflow for drive-by contributions is to allow any random user (who logs in via atlassian, github, or heptapos) to push a branch (or topic branch) to the pypy/pypy repo, but only authorized users (they call them "project masters" can merge ("publish") from those branches to the main development branches. We could override this, as explained on the workflow page.

...

- decide which repos to abandon. On the issue above I proposed transferring only a subset of our bitbucket repos, please make sure your favorite is included I suppose I'm +0.5 on dropping the old and unused repos. We still have them around anyway in the sense that any one of us with a copy can re-publish them somewhere at any point. (See also below.)

...

- block changes to the active branches (default, py3.6, py3.7 of pypy, and the HEAD branch of the other repos); any new contributions will have to be done via the heptapod instance So you mean, we would still be allowed to push into the various repos on bitbucket as long as it is not on these main branches? Unsure why.

In order to block changes you need to navigate the UI and disallow each branch separately. It is simply too much work. This is all temporary, on May 31 those repos dissapear.

...

- what to do about downloads? It is not clear that the gitlab instance has a place for artifacts. Assume we find a solution, how far back do we want to keep versions? Would it be possible to just keep this on bitbucket and point to it? I understand the idea of stopping all mercurial services, but a priori they won't delete everything else too? If they do, maybe we just need a hack like convert the pypy repo to git on bitbucket (and then never use it). Same for the wiki. And for all our many-years-old dead repos---we can convert them in-place to git if that means they can stay there.

Of course all this is assuming we're fine with keeping a few historical things on bitbucket. If you decide you'd prefer to have nothing more to do with bitbucket soon and they should die instead of continuing to get however little publicity we'd continue to give them by doing that, then I would understand too.

In order to stay on bitbucket, we would have to - reame pypy/pypy to pypy/pypy_hg - create a new pypy/pypy using a git repo - transfer the downloads and wiki to the new repo As May 31 gets closer, we will have to decide what is easier: these steps or something else. I am personally done with bitbucket/atlassian. Hosting the downloads should be simple, if we had the bandwidth we could do it on the buildbot master. Perhaps we could ask the PSF if we can upload them to www.pypy.org/downloads/files. Hosting the wiki is a bit more complicated. Perhaps since we never get outside edits anyway we could just incorporate it into the pypy.org website as static pages.

A bientôt,

Armin.

Matti

On 6. Feb 2020, at 07:55, Michał Górny <mgorny@gentoo.org> wrote:

Finally, we're living in times where people start caring about their personal data. Even if it's not explicitly personal, people have their doubts about registering on yet another site that's likely going to track them in ways unimaginable.

In as far as tracking is concerned, their data is way safer with Heptapod as compared to Microsoft ;-) Sent from my iPad

On 6. Feb 2020, at 07:24, Matti Picus <matti.picus@gmail.com> wrote:

I am personally done with bitbucket/atlassian. Hosting the downloads should be simple, if we had the bandwidth we could do it on the buildbot master. Perhaps we could ask the PSF if we can upload them to www.pypy.org/downloads/files. Hosting the wiki is a bit more complicated. Perhaps since we never get outside edits anyway we could just incorporate it into the pypy.org website as static pages.

In as far as downloads are concerned, you could try to apply for an account on the OSU OSL mirroring service - they have been hosting downloads for Midnight Commander for almost for a decade by now, and we’ve been very happy with their service. You just scp stuff in your personal directory and trigger a mirroring script per ssh - it gets propagated to the mirrors and there you go - excellent speed, safe storage. Sent from my iPad

Hi there, I'm Heptapod main maintainer. On 2/6/20 7:23 AM, Matti Picus wrote:

...

...

    - disallows personal forks on the instance -1  (any reason why?)

This is a Octobus decision, so maybe Georges can chime in. Yes, I've just subscribed to that effect. I'll try and answer the different concerns separately. My understanding is that because the heptapod offering is on a trial basis, they do not want to open up the possibility for random individuals to open "groups" on the instance. In order to fork a repo, you need a personal "group" as the target. This means that all contributions must be done on the pypy/pypy repo.

This is not completely exact. There are two different aspects to it - Personal forks are just not implemented in Heptapod (the software) yet [1]. I've also written a bit in the FAQ [2] about that. As a side note, it's more complicated to implement properly forks and merge requests from them than other lacking features. - It is true that we don't want to make foss.heptapod.net a space where anybody can create repositories, because we don't have infinite capacity (but we hope we can grow) nor enough work force to watch for illegal content at the scale that implies. But that shouldn't apply to personal forks once we have them.

Their workflow for drive-by contributions is to allow any random user (who logs in via atlassian, github, or heptapos) to push a branch (or topic branch) to the pypy/pypy repo, but only authorized users (they call them "project masters" can merge ("publish") from those branches to the main development branches. We could override this, as explained on the workflow page.

First I should say that "Master" is standard GitLab terminology in the version we're based upon, but has been renamed to "Maintainer" in later versions. It means you have all rights on the repository, except for the like of removal and transfer [3] We also plan to introduce an intermediate role, that could be labelled "Publisher". All of this is indeed backed by the "phases" concept in Mercurial, in which changesets can be "draft" (amendable) or "public" (set in stone) and the fact that topics are additional metadata for draft changesets only. In Heptapod, by default, we enforce that conversely all drafts must have topics. So, the default Heptapod workflow is to grant the Contributor role to people that wish to contribute – they can push topics and submit merge requests – whereas full commit rights translate in the Master role. This is explained and motivated in more detail in the FAQ [4] and in the Octobus blog post [5]. An important implication of all this is that it makes activating the evolve extension [6] almost necessary in practice. It's not meant to be mandatory by itself, see "Mutability and Evolution"  in [5], but once a draft changeset has been amended you'd get surprising warnings if you don't have evolve. Note also that open Bitbucket pull requests are imported as topics [7], and that involves amendments. To conclude, we know that the picture is not perfect and that we could make the transition easier and clearer. We're working on improving all of that, but we have lots of things to do, and we need actual user feedback - such as yours - to prioritize them properly. We're listening. Best, PS: I'm considering coming to the next PyPy sprint in Switzerland. [1] https://foss.heptapod.net/heptapod/heptapod/issues/24 [2] https://heptapod.net/pages/faq.html#forks [3] https://docs.gitlab.com/ce/user/permissions.html [4] https://heptapod.net/pages/faq.html#workflow [5] https://octobus.net/blog/2019-09-04-heptapod-workflow.html [6] https://pypi.org/project/hg-evolve/ and https://www.mercurial-scm.org/doc/evolution/user-guide.html [7] https://foss.heptapod.net/heptapod/heptapod/issues/106 -- Georges Racinet https://octobus.net, https://heptapod.net GPG: BF5456F4DC625443849B6E58EE20CA44EF691D39, sur serveurs publics