FYI: githubs hat neue, Copyleft-feindliche Terms of Service

[Daniel Baumann]

Hallo Torsten,

On 03/02/2017 04:06 PM, Mähne Torsten wrote:
> Umso wichtiger wäre es, dass es endlich eine von der ITS langfristig unterstützte Hosting-Lösung für Git-Repositories mit Issue- und Pull-Request-Tracking gäbe

absolut.. machen wir ;)

wir haben das waehrend den letzten ca. 2 jahren schon mehrere male mit
diversen leuten besprochen, zuletzt letzten herbst besprochen..

hier die "kurze" zusammenfassung der wichtigesten punkte (wenn
du zu einem/mehreren punkte etwas genauer ausgefuehrt haben moechtest,
einfach sagen):

  * der bestehende git server wird baldmoeglichst von uns so-oder-so
    auf:
    - stretch aktualisiert
    - auf cephfs migriert
    - gitweb wird durch cgit verwendet

  * weil aktuelle git versionen (im gegensatz zu "frueher" von vor 2
    jahren, stichwort dumb protocols, siehe git manpage) nun effizient
    ueber https clonen koennen, und weil clonen ueber git:// unsicher
    ist (MiM-attacks), werden wir git:// durch https:// ersetzen.

    das heisst aber dass die clone urls fuer git:// wegfallen,
    und fuer https neue dazu kommen. fuer ssh bleiben die clone urls
    gleich.

    auf allen anderen betreuten git servern habe ich all dies schon vor
    ca. 1 jahr vorgenommen, fuer die bfh koennen wir aber diesen
    wechsel weil inkompatible aenderung nicht waehrend dem semester
    machen - daher warten wir auf die naechste semester pause.. d.h.
    die migration findet im sommer 2017 statt (FS17 hat nicht gereicht
    weil ceph erst produktiv per 13.2., und danach war moodle migration
    prioritaet).

  * zusaetzlich zu cgit werden in einem zweiten schritt pagure.io
    on-top installieren, siehe https://pagure.io. dieses bietet einen
    lightweight aufsatz mit bugtracker etc. an.

  * echtes bug tracking mit tiefer integration kann man aber nur mit
    einem vernuenftigen, richtigen bug tracker machen (e.g. request-
    tracker), dieser geht in den naechsten paar tagen online, dazu
    spaeter mehr.

  * gitlab beobachte ich schon sehr lange, dazu folgende punkte:
    - fuer uns als ITS werden wir selbst nie gitlab oder eine
      einderweitig komplexe hosting platform verwenden (fyi; das hat
      nichts damit zu tun was wir fuer lehre/forschung/entwicklung
      machen).

      grund: da wir alles in git repos haben, muss im desaster fall
      (ueberschwemmung RZ bern o.ae.) der git server sofort und ohne
      weitere komplexitaet/abhaengigkeiten online/restored werden
      koennen (in biel). d.h. git.bfh.ch wird soll aus unserer sicht
      nur (kiss) "einfacher" git server sein.

      erst wenn der git server wieder da ist, koennen wir weitere
      basisdienste (dns, dhcp, pxe, debian deployment, debian paket
      archive, etc.) wieder hochfahren und damit services restoren.

      -> mit gitlab und aehnlichen faellt man ins klassische
      bootstrapping problem.

   - an gitlab sind wir momentan als alternativ angebot fuer lehre/
     forschung/entwicklung nicht interessiert. zumindest solange
     es nicht in debian stable ist (und bleibt; ich verweise auf die
     debian-devel diskussion dazu von letztem fruehling und
     sommer/herbst, die zukunft ist momentan sehr ungewiss) ist es
     grundsaetzlich kein thema.

     unser standpunkt:
     + gitlab ist eine relativ komplexe ruby-on-rails applikation.
     + wir haben kein ruby know-how und ansonsten einen auf
       python ausgerichteten stack den wir weiter verfolgen.
       # es gibt einen unterschied zwischen "install and forget"
         (immer periodisch auf update knopf duecken in der hoffnung
         alles geht) wie das momentan bei gitlab der fall ist,
         und eines "echten" service-angebots.
       # ersteres kann man fuer zu hause machen, oder wenn keine
         weiteren ansprueche an die applikation vorhanden sind. d.h.
         bestenfalls "best-effort" support, wenn ueberhaupt.
       # einen echten, stabilen service koennen wir nur garantieren
         wenn wir die applikation genug gut betreiben um serioesen
         betrieb zu machen. bei gitlab ist das aus erwaehnten gruenden
         ohne sehr viel aufwand unsererseits nicht moeglich.
       # beispiel: angenommen wir wuerden gitlab "best-effort"
         betreiben, dann wuerde das z.b. heissen dass wir genau keine
         aenderungswuensche/einstellungswuensche/integrationswuensche
         abweichend vom initialen default respektieren wuerden, und
         falls es ein problem bei einem upgrade geben wuerde, wuerden
         wir einfach neu installieren. d.h. ggf. alle history weg. das
         ist denke ich auch nicht in eurem sinne.
     + wir sehen wenig vorteile von gitlab gegenueber einem
       traditionellen git server mit pagure.io und ssh keys aus ldap via
       IDM, aber einige, insbesondere betrieblichen nachteile.

    - als als project management/hosting tool favorisieren wir taiga.io
      welches sich nahtlos an einen git server anbinden/integrieren
      laesst.

> Immerhin befindet sich doch gitlab seit geraumer Zeit in Debian Unstable

hast du dir mal die bugs angesehen dies hatte und die es immer noch hat?
insbesondere was upgrades von n auf n+1.

abgesehen davon, obwohl es jetzt in testing ist.. bis zum release von
stretch kann es jeden tag ohne vorwarnung rausfallen.

last but not least: der git server ist, wie erwaehnt, kernbestandteil
unserer eigenen infrastruktur. da koennen wir uns einerseits wenig
"experimente" erlauben und andererseits upgrades/aenderungen auch nur
sehr zurueckhaltend (wenn inkompatibel nur wenn absolut notwendig, lange
vorankuendigungszeiten, migrationen nur in semesterpausen, etc.)
durchfuehren. maximale zuverlaessigkeit fuer git server ist ein feature,
nicht ein bug ;)

Gruesse,
Daniel

-- 
Berner Fachhochschule / Bern University of Applied Sciences
IT-Services / Team Infrastructure Services
Daniel Baumann
IT System Engineer Linux
___________________________________________________________
Dammweg 3, CH-3013 Bern
Phone direct +41 31 848 48 22
Phone Servicedesk +41 31 848 48 48
daniel.baumann at bfh.ch
https://servicedesk.bfh.ch
https://www.bfh.ch
https://linux.bfh.ch