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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
