Notes / Minutes / Whatever, Alioth Sprint 2017, Hamburg
Attendees
* Lars
* Phil
* Ganneff
* weasel
* formorer
* nodens
* stappers
Disclaimer: please don't use the minutes of the sprint to discuss things.
IRC #alioth and mailing list are here for this very purpose
Friday
- Comparision of various git-"Service" Packages.
gitlab, gitolite, pagure and gogs are candidates (we have knowledge of)
Made a featureset matrix to compare:
Y=Yes, M=Maybe/Some kind of/Limited, N=No
Feature Gitolite Pagure GitLab Gogs
Authentication Y M Y Y
Authorization
Groups Y Y Y Y
Teams Y Y Y Y
ACLs complicated Y Y Y
Frontend
Browse Y Y Y Y
Notifications N Y Y Y
Hooks M Y Y Y
PullRequests N Y Y Y
Fork N Y Y Y
Edit N Y Y Y
Bonus Features:
Read/Write-Split Y M N N
Issues N Y Y Y
GitPages N M Y N
CI N M Y N
Mirroring N N M N
Code Review N N Y N
Mail Control N Y Y N
API N Y Y Y
Misfeatures / problems
CLA n n Y n
Open Core n n Y n
Gitolite:
ssh-based git administration
Pagure:
Development hosting used by Fedora.
Python Layer over Gitolite
Having a LDAP service seems mandority
Gitlab:
Gitlab upstream in the past opensourced features from the commercial
variant on request (GitPages for Gnome as an example).
They offered help / to accomodate us when we need it. (We would like
to see the mirroring feature in the community edition)
Gogs:
"Go Git Service"
Gitlab clone in Golang
(MIT Licence)
gitea: (greek word for "good view")
fork of Gogs
gitano:
Daniel Silverstone's git server that is administerable entirely via
git (AFAIK).
more like gitolite than gitlab
Kallithea:
None of the participants knows enough about Kallithea to fill the
feature matrix.
(similar, but smaller review: https://wiki.debian.org/Alioth/GitNext)
* re: dsa or non-dsa machine:
Using weird 3rd party apt sources and packages would put a large
burden on DSA, so this new machine will be maintained by
a dedicated set of admins. Initially, this set consists
of Ganneff, formorer, and Phil.
Administration of the webservice will be open to non Debian Developers.
* Decision: We are going with GitLab and we are using upstreams packages.
-> Debian packages are same in stable, testing and unstable, and so a
bit stale compared to upstream:
- Debian packages are at 8.13. The 8 series goes to 8.17 already, and there is
already 9.0 to 9.4 on top of it.
- 8.13 being from October 2016, 8.17 from March 2017, 9.0 from March 2017.
- we understand and acknowledge that packaging such a big piece of software
is a lot of work, especially regarding architectural changes, but we will
need fresher versions especially if we want support (consulting) from
Gitlab, request new features to go in the CE edition, etc. Also, we are
in a hurry.
-> Debian packages do follow the policies and standards of Debian (GOOD!), but
it means that anything you find about gitlab does NOT fit. Howtos, tips, whatever,
everything is assuming the upstream look. -> Added Maintenance Burden.
Note: If, at some point in the future, the package as in Debian, is the better
choice, we can switch.
* We start developing the service on salsa.debian.net - (salsa--where we keep our secret sauce?)
Once the service is available, people can move their projects and repositories
there from alioth. (They can also move to other serivces.) Eventually, alioth will be retired.
People MUST move their own repositories, we won't do a mass move. This helps
to sort out outdated and unused repositories.
- We are, for now, only focussing on the git service. There will probably
be proposals on how to deal with mailinglists. Actual use of other services
might be reconsidered at a later time, but it's highly likely there will
be no generally-available, managed replacement services for other things.
- Discussing other services:
* Mailinglist support:
see separate document "Mailinglists"
* Subversion Repositories:
see separate document "Subversion"
* CVS / Mercurial / Bazaar / Darcs
see separate document "VCS - non-git"
* Generic shell server / web hosting - we do not want this at all on
debian machines.
* Whatever general other things people run on alioth. Its a mess, not what
alioth is for.
* SSO -- alioth is currently used for nm.d.o. gitlab offers oauth2:
https://docs.gitlab.com/ee/integration/oauth_provider.html
- New user stuff:
Encourage login with @debian.org to detect DDs.
Non-DDs register and use their own address, just dont have DD rights.
Login with e-mail address doesn't mean you need to use that to receive
mail, you can setup different addresses for.
It seems that gitlab doesn't take notice of the @.*$ part of usernames,
so we need to enforce non-DDs to have -guest (or similar) on their name.
Note: usernames and groupnames share the same namespace
It seems actually difficult to modify the registration to enforce that.
It is probably simpler to create a separate page to register that will use
gitlab's API
Server for git is 'godard'
git clone ssh://git.debian.org/git/mirror/salsa.debian.net-godard-ansible
Michael Lustfield <michael@lustfield.net> provided a gitea instance.
http://gitea.debian.net
# Things to be done/prepared/discussed during the sprint (proposal)
## Timeline
* when/whether do we publicly discourage registration of users / projects / ???
- yesterday
* when/whether do we put everything in read-only mode?
- gits probably some time after replacement service is available
* when do we shut down alioth?
Answer: at least before end of security support of wheezy (may 2018)
## Announcements (wild propasal)
* 2017-08-?? communicate the future of alioth and the related services
(content: see below "Outline of the future of Alioth")
* 2017-08-?? communicate the possible future for mailinglists
(see the announcement draft "MailingList-1")
* 2017-08-?? communicate the future of version control
(see the first draft "VCS-1")
* 2017-08-?? announce the new development platform
(refer to the wiki documentation (https://wiki.debian.org/Salsa), announcement draft (TODO))
* 2017-??-?? notification/reminder: read-only for everything
* disable registration
* disable project creation
* mailinglists reject incoming mail
* version control write access is disabled
(see the second draft in "VCS - non-git")
* 2017-??-?? final note: goodbye alioth
(announcement draft (TODO))
## Outline of the future of Alioth
* timeframe of services being shut down
* refer to separate mails:
* announcement of "salsa" (git)
* mailinglists
* version control (non-git)
* mention services without a (known/planned) replacement:
* SSO (nm.d.o?) - out of scope - and its not plain alioth anyways, alioth is only one data source
* more about SSO below
* shell / web hosting / cron / ???? - shell hosting, web hosting (besides gitlab pages) is out of scope (and always was)
* of course - out of scope. We will mention it as discontinued (due to being out of scope) in order to avoid support questions.
## about SSO
> Isn't db.debian.org the backend that knowns about all DD?
SSO, as it is right now, is NOT a user managing thing. SSO is ONLY
taking existing users from one or more (two right now, db.d.o/alioth)
backends, and allows them to have a single sign on on connected debian
services, nm.debian.org being the biggest of it, DebConf pages the next
one (that i know of).
If someone is willing to invest the time and work to make SSO fly up and
be THE one point other things can connect to, meaning that it eats DD
data from db.d.o but does its own user management for non-DDs, and also
willing to maintain that over time - and then also add stuff like being
an ouath provider, SAML something, whatever those things are called by
now, so that applications/services can easily be connected to it - then
setups like gitlab/gitea/whatever can go and use it as a provider, and
not the other way round.
I am pretty sure the current maintainers of sso would love to get help,
possibly to the point of being happy to entirely give it to someone who
really wants to invest the time and work, also i cant speak for them, so
talk to them for more.
## Documentation of the new development platform
* see https://wiki.debian.org/Salsa/Doc
** some TODOs are missing