Commit d5ecdbc8 authored by Georges Racinet's avatar Georges Racinet 🦑
Browse files

Hosting Requests: new criteria and wording

- Salvage from Bitbucket is no longer relevant.
- Hosting in new top-level groups or personal namespaces is best
  for permission handling (giving full autonomy to project maintainers)
parent 5f20f4ad2ce8
......@@ -5,46 +5,47 @@
- Project Maintainers:
- Project License:
Please explain here why they meet our current criteria.
All details are in the [invitation announcement](
To recapitulate, these are:
Please explain here how they meet our current criteria.
### Main criteria
- [ ] Free / Open Source
- [ ] main development repositories
- [ ] you are an official maintainer of the project
- [ ] agreement to acknowledge where appropriate the help provided by Octobus
and Clever Cloud by hosting on
### Priority Criteria
### Additional information
Knowing this can help in case there are constraints on resources and/or
administrators availability at the time of the request. It can also help us
suggest the right solution for the needs of the project.
- is the project officially released? In downstream distributions or
packaging systems?
- estimation of the user base if possible, or number of downloads,
reverse dependencies…
- number of maintainers and regular contributors
- where is the project currently hosted? Are there issue trackers,
review systems, CI/CD to hook to or to replace somehow?
### Hosting type
What would you like to have?
- [ ] currently hosted on Bitbucket
- [ ] officially released
- [ ] a top-level group
- [ ] a project in an existing group
- [ ] just a project in your personal namespace
## Post approval maintainer task list
for explanations.
- [ ] Hosting Request assignee has repository membership on Bitbucket
- [ ] Heptapod / Bitbucket accounts link
- [ ] Reviewing [Heptapod workflow](
## Post import maintainer task list
- [ ] Clone the project afresh from
- [ ] Check that the repository looks good: branches are as expected in the
clone and the web interface, with no `wild` branches unless
there are known multiple heads.
- [ ] Check that issues are imported, and notably that all open issues are
there. Watch for attachments etc.
- [ ] Check that Pull Requests are imported, and in particular take a close
look at the resulting open Merge Requests - they should be backed by a
topic. Make sure you can navigate these in the fresh clone.
- [ ] Check that against, `hg outgoing` and `hg incoming`
from a prior clone are as expected
- [ ] Add the Octobus and Clever cloud acknowledgement at the selected place.
- [ ] Communicate about the migration to help others to aware of the options
(for example on mastodon, twitter, bitbucket thread, mailing list, …)
......@@ -10,54 +10,45 @@ restricted to people from Octobus and Clever Cloud.
See the [separate page about administration](
## Projects to be imported from Bitbucket
## Admissible projects
FOSS projects are welcome on, with restrictions primarily
due to the resources being finite.
On this service, users are not allowed to create new projects at will.
[the announcement]( for
eligibility criteria and more explanations.
All Free and Open Source projects are welcome on,
as far as the current resources permit.
### Things to be aware of
If you want some project to be hosted, please create an issue on the present
project with the "Hosting Request" template. Upon approval, we will usually
allow you to create what you need.
After import, most issues and merge requests will be owned by the special
"Bitbucket Importer" account.
Heptapod does not support personal forks yet.
### Import test run and validation
We're going to do a test run first, so that the maintainer can verify
that everything looks good. At this stage, the project will typically be
If the maintainer validates the import, two things can happen
1. No significant change (push, issue etc) has happened on Bitbucket side since
the test run: the maintainer can just switch the project to public.
2. A new import is needed. That probably means the project has some traffic,
and it's probably a good idea then to decide a switchover time and warn
contributors in advance that new content created Bitbucket-side will just
be ignored from that time.
From there, we can either get back to validating the import, or just make
it public right away (with basic checking by admins of
Note: to avoid confusing situations, we require that the person requesting
hosting be an official maintainer of the project, or to have been publically
asked to do so by a maintainer.
### Maintainer task list for the import to happen
Once the Hosting Request is approved, it should be assigned to one of the site-wide
administrators, who will perform the actual import.
Once the Hosting Request is approved, it should be assigned to one of the
site-wide administrators, who will give the needed rights or create a group
with the proper ownership.
#### Identification
#### Make sure that your Bitbucket and Heptapod account are tied together.
We need to be sure that authors hosting requests are who they claim to be.
This is to be sure that you are indeed who you're supposed to be.
One way to do that is to tie their identity on to a
well-known external one (currently GitHub and Bitbucket are supported):
In Heptapod, go to your settings, then to the "Account" menu entry. Under
"Social sign-in", if the Bitbucket button displays "Connect", then click it,
you'll be redirected to Bitbucket to review the permissions.
After that you'll be able to log in to Heptapod with your Bitbucket account.
If that is not practical to you, other possibilities include
- email address verification (site administrators can see it, sometimes
that can be enough)
- well-known GPG key
#### Review the [Heptapod workflow](
As a complement to the FAQ, please also read
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment