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.pi...@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
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev
