[pypy-dev] Moving PyPy to https://foss.heptapod.net

Matti Picus matti.picus at gmail.com
Thu Feb 6 01:23:45 EST 2020


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



More information about the pypy-dev mailing list