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