Categories
Pages
-

IT Center

The GitLab Project LifeCycle goes into the second round

August 16th, 2021 | by
Symbol image: A circle of arrows.

Source: Pixabay.de

GitLab is used at RWTH Aachen University with pleasure and actively. However, after projects have been processed, a lot of data often accumulates that is no longer used. To prevent a mountain of data waste from piling up in GitLab, a Project LifeCycle for RWTH was designed and introduced at the IT Center. In March 2021, it went live.

In the first few weeks, we received a number of suggestions and requests for adjustments to the process from users. So that these could be examined in detail by the responsible department, the GitLab Project LifeCycle was paused for the time being.

The review and revision phase has now been completed. In this article, we present the adjustments made with the help of the feedback.

1. Archive feature

Sometimes you have projects that are not currently being changed or used, but you still need them on a regular basis. Or you have to keep them for a longer period of time for various reasons.

To exclude such projects from the GitLab Project LifeCycle, we explicitly point out the GitLab feature “archiving”. As soon as this is activated, the corresponding project is put into Read Only mode. The GitLab Project LifeCycle will then ignore these projects.

You can find more information and instructions on the archiving feature on IT Center Help.

2. Adjustment of the deadlines

Based on feedback, the GitLab Project LifeCycle deadlines have been adjusted as follows:

  • The time period after which a project without activity is marked as inactive will be increased from 12 to 24 months.
  • The period between notification of marking as inactive and final deletion of the project will be extended from 8 weeks to 25 weeks.
  • The validity period for extension requests remains 12 months.

3. Email reminders

We live in the digital age, where we are virtually swamped with messages every day on a variety of communication channels. It’s not uncommon for a single email to get lost in the inbox.

That’s why the GitLab Project LifeCycle reminds you if a project has been marked as inactive. Within the 25-week period between marking a project as inactive and deleting it, several emails will be sent. So if you have not taken action after the first email, you will receive another email in the 12th and 24th week. This reminds you that the corresponding project is currently still marked as inactive.

If no new activity on the project, no archiving of the project and also no request for extension is received, the deletion of the project will be triggered at the end of the period.

After the deletion of the project, a project export is available to all project owners for another 4 weeks. The export can then be downloaded via a randomly generated download link.

Flowchart of the GitLab Project LifeCycle.

The simplified GitLab Project LifeCycle. (Source: IT Center)

 

We see these adjustments as a suitable compromise between your feedback and the vendor requirements around the GitLab Project LifeCycle. We hope for your understanding if your suggestion could not be considered.

The GitLab Project LifeCycle restarts on 17th of August 2021 with the aforementioned adjustments.

You want to know more about GitLab at RWTH Aachen University? Then we recommend the blog post Nice to know: The first steps in GitLab at RWTH Aachen University. Have a look!

 

Further information about the GitLab Project LifeCycle as well as the detailed terms of use can be found on IT Center Help.

 

Responsible for the content of this article are Matthias Becker and Linda Jörres.

8 responses to “The GitLab Project LifeCycle goes into the second round”

  1. Sehr informativer Beitrag, vielen Dank

  2. Bernhard says:

    Es mag den Verantwortlichen im IT Center immer noch nicht aufgefallen sein, aber ein wesentlicher Bestandteil einer Versionskontrollsoftware ist, dass man sich darauf verlassen kann, alte Versionen stets wiederherstellen zu können. Ich finde es wirklich schade, dass dies bei der Konzeption der Gitlab-Bereitstellung übersehen worden ist.

    Wenn die RWTH die dauerhafte Bereitstellung der eingerichteten Repositories ressourcenmäßig nicht stemmen kann, dann sollte sie die Nutzungsbedingungen ändern und z. B. nur Forschungsdaten zulassen (zurzeit Forschung, Lehre, Open Source). Die Projekte nach einer Weile – auch mit Nachfrage – zu löschen, ist jedenfalls das komplette Gegenteil eines zuverlässig bereitgestellten Versionskontrolldiensts.

    https://de.wikipedia.org/wiki/Versionsverwaltung#Hauptaufgaben

    • Jörres, Linda says:

      Hallo Bernhard,

      vielen Dank für deinen Kommentar. Zur Beantwortung deiner Punkte haben wir unsere Fachabteilung kontaktiert.

      1. Git ist nur für Projekte der Lehre zugelassen, oder OpenSource. Forschung ist nicht gestattet, wie du in den Nutzungsbedingungen nachlesen kannst:
      https://help.itc.rwth-aachen.de/service/ubrf9cmzd17m/article/1a0cfe327ffd46d7a62ab48df29c5b72/

      2. Wie im obigen Blogbeitrag unter “1. Feature „Archivierung“” beschrieben, gibt es die Möglichkeit Projekte zu archivieren, wenn sie nicht aktiv genutzt werden. Dann fallen sie nicht in den GitLab Project LifeCycle.

      3. Weiterhin ist es jederzeit möglich, in einem Projekt wieder aktiv zu werden – dann wird die Markierung entfernt und das Projekt nicht gelöscht.

      Solltest du weitere Fragen haben, wende dich gerne an unsere Kolleginnen und Kollegen vom IT-ServiceDesk (servicedesk@itc.rwth-aachen.de).

      Viele Grüße,
      das IT Center Blog Team

      • Bernhard says:

        Vielen Dank für die Antwort.

        Zu 1: Das hatte ich in der Tat falsch in Erinnerung. So herum ist es natürlich sehr schade; m. E. sollte die Universität diese Plattform gerade der Forschung bereitstellen, denn diese ist wohl am meisten auf zuverlässige und vertrauliche Speicherung solcher Daten angewiesen.

        Zu 2: Ja, ich weiß, dass man Projekte archivieren kann. Das hilft allerdings nicht bei Projekten, die sich naturgemäß nur langsam ändern. Solche müssen jetzt durch völlig sinnlose Änderungen “am Leben gehalten werden”, was das komplette Gegenteil von aussagekräftiger Versionierung ist. Das bedeutet, man muss sich in git log oder git blame ab sofort durch eine Menge sinnloser Änderungen wühlen, bis man das findet, was man eigentlich sucht.

        Zu 3: Siehe 2.

        Ich weise noch einmal darauf hin, dass DAUERHAFTE Vorhaltung alter Versionen eine zentrale Aufgabe eines Versionskontrollsystems ist. Dass dabei in manchen Fällen Datenmüll durch nicht mehr genutzte Projekte entsteht, ist ein unerfreulicher Nebeneffekt; das hätte die RWTH sich vor der Bereitstellung von GitLab überlegen müssen. Jetzt rückwirkend Projekte zu löschen, entwertet jedenfalls die Plattform sehr.

        • Jörres, Linda says:

          Hallo Bernhard,
          vielen Dank für deine Rückmeldung.
          Wir haben für dich noch einmal unsere Fachabteilung kontaktiert. Hier die Antworten:

          Zu 1.: Der erste Hinweis mit der Plattform für Forschung ist leicht beantwortet: Dafür haben wir eine zweite GitLab-Instanz git-ce.rwth-aachen.de.
          So wie es in den Nutzungsbedingungen steht:
          ——
          “GitLab wird auf zwei unterschiedlichen Serverinstanzen angeboten.

          Die Instanz „git.rwth-aachen.de“ wird mit einer „GitLab for Education“ Lizenz betrieben und darf nur für die Ausbildung von Studierenden und das Entwickeln von OpenSource Software ohne Gewinnerzielungsabsicht genutzt werden. Die Einhaltung der zugrundeliegenden Lizenzbedingungen von GitLab (https://about.gitlab.com/terms/#edu-oss) ist dabei verpflichtend.

          Die Instanz „git-ce.rwth-aachen.de“ unterliegt einer „Community Edition“ Lizenz. Sie bietet gegenüber der „GitLab for Education Edition“ weniger Funktionen, die Lizenzbedingungen erlauben aber eine freiere Nutzung.”
          ——
          Die kompletten Nutzungsbedingungen kannst du auf IT Center Help finden:
          https://help.itc.rwth-aachen.de/service/ubrf9cmzd17m/article/1a0cfe327ffd46d7a62ab48df29c5b72/

          Zu 2.-3.: Es ist klar, dass es Projekte gibt in denen mehr Aktivität herrscht als in anderen. Wenn jedoch für 2 Jahre keine Aktivität festzustellen ist, sollte ein kleines Lebenszeichen alle 2 Jahre nicht allzu viel verlangt sein, wenn das Projekt tatsächlich noch benötigt wird. Zumal hier sämtliche Aktivitäten für ein Projekt gezählt werden: Commits, Pushes, Merges, Issues, Branches, Mitgliedschaftsänderungen, Wiki Änderungen, Kommentare, etc.
          Ansonsten kann man es mit dem Archiv auch für längere Zeit stilllegen und bei Bedarf wieder aus dem Archiv herausholen.

          Darüber hinaus werden Projekte nicht einfach so gelöscht, sondern mit Hilfe des GitLab Project LifeCycle mehrmals nachgefragt, ob das Projekt noch benötigt wird.
          Mit einer Aktivität, dem Archiv und den Verlängerungsanträgen haben wir hier eine gute Grundlage für mögliche Optionen.

          Solltest du weitere Fragen haben, wende dich gerne an unsere Kolleginnen und Kollegen vom IT-ServiceDesk (servicedesk@itc.rwth-aachen.de).

          Viele Grüße,
          das IT Center Blog Team

  3. Michael Gerhards says:

    Zitat “Deswegen erinnert euch der GitLab Project LifeCycle, falls ein Projekt als inaktiv gekennzeichnet wurde.”
    Welche Rechte muss man dann innerhalb des Projektes haben, um erinnert zu werden?

    Zitat von IT Center Help: “Wird ein Projekt 24 Monate lang nicht genutzt, werden alle Projektinhabenden per E-Mail darüber informiert, dass das genannte Projekt durch den Projekt-Lifecycle als inaktiv markiert wurde.”

    Projektinhabenden ist jedoch nicht sauber definiert, insbesondere für Gruppenprojekte. Man kann Owner der Gruppe sein. Man kann auch Maintainer des Projektes sein. Dann kommt noch hinzu, dass Gruppenrechte hierarchisch an Untergruppen vererbt werden. Bis hier hin klappt alles. Problematisch wird es allerdings, wenn man Owner aus einer anderen nicht-hierarchischen Gruppe einer Gruppe hinzufügt. In diesem Fall werden die vererbten Owner NICHT benachrichtigt.

    • Jörres, Linda says:

      Hallo Michael,

      vielen Dank für deinen Kommentar. Wir haben zur Beantwortung deiner Fragen unsere Fachabteilung kontaktiert.
      Hier die Antworten:

      1) “Welche Rechte muss man dann innerhalb des Projektes haben, um erinnert zu werden?”
      Antwort: Es werden alle “Owner” eines Projekts oder bei Gruppenprojekten alle “Owner” der Gruppe sowie allen übergeordneten Gruppen informiert.
      Dabei wird zum Zeitpunkt der Erinnerung immer vom aktuellen Status ausgegangen, den die Mitglieder innehaben.

      2) “Projektinhabenden ist jedoch nicht sauber definiert, insbesondere für Gruppenprojekte. Man kann Owner der Gruppe sein. Man kann auch Maintainer des Projektes sein.”
      Antwort: Bei Gruppenprojekten haben wir absichtlich die Owner der zugehörigen Gruppe gewählt, da die höchste Berechtigungsstufe von Projekten in einer Gruppe Maintainer ist. Aus unserer Sicht ist es demnach bei Gruppenprojekten am sinnvollsten direkt die Owner zu informieren, wenn ein Projekt schon sehr lange Zeit inaktiv ist, da es in den meisten Fällen keine direkten Mitglieder in Gruppenprojekten gibt und die Berechtigungen aus der zugehörigen Gruppe vererbt werden.

      3) “Dann kommt noch hinzu, dass Gruppenrechte hierarchisch an Untergruppen vererbt werden. Bis hier hin klappt alles. Problematisch wird es allerdings, wenn man Owner aus einer anderen nicht-hierarchischen Gruppe einer Gruppe hinzufügt. In diesem Fall werden die vererbten Owner NICHT benachrichtigt.”
      Für die Beantwortung dieses Punkts benötigt die Fachabteilung ein Beispiel anhand eines konkreten Falls. Hierzu wird dich unser IT-ServiceDesk kontaktieren, damit dir schnellstmöglich weitergeholfen werden kann.

      Viele Grüße,
      das IT Center Blog Team

Leave a Reply to Bernhard Cancel reply

Your email address will not be published. Required fields are marked *