2018-09-10

Topics

  • Robert: Template changes: hierarchy, testing, win32, meta-provides
  • Robert: merging different versions of recipes
    • projects-citec.template + projects-citec-csra.template: access, scm.credentials
    • icl*.project,
  • Robert: Orchestration jobs
    • renaming: <distro>-<mode>-orchestration --> orchestration-<mode>-<distro>
    • ci-deploy mode: use cases?
    • pending changes: drop initial / from scratch vs. resume
    • cancelling orchestration job should cancel all pending jobs (and disable them again)
  • Jan/Martin: Catalog and GDPR
  • Jan: YAML syntax
    • Includes (replace opensource:// mechanism?)
    • String scalars
    • Comments
  • Jan: Generator features
    • validate command
    • analyze command
    • platform-requires command
    • report command
    • changelog
    • on-error default
    • Dependency report
  • Jan: Automatic GitHub template switch?
  • Sebastian: Include of Distros (sourcing to prevent duplication and allow separation)
  • Sebastian: Separation of third party and own development (no tests, no rebuild, etc.)
  • Sebastian: Freezing of Versions (reproducibility)
  • Robert: resolving dependencies of ROS packages
    • cmake vs. package.xml?
    • build/test/run depends?
  • Robert: handling system dependencies
    • listing (system)-distribution-specific dependencies is highly redundant
    • ROS uses rosdep for a mapping of high-level names to actual packages (reuse this approach and corresponding YAML files)
    • distribution-provided package vs. system-provided package: source-build should take precedence
  • Sebastian:

Protokoll

Report des Zustands

  • Syntaxumstellung
    • Kommentare
    • Skalare Knoten mit Strings
      • Zeilenumbrueche
      • Keine single/double quotes (Besonderheit: branches mit Versionsnamen, z.B. 0.12)
      • Pipe+Neue Zeile als Einleitung fuer Shellskripte (Einrueckung relevant) -> Doku?
    • Includes via YAML language extension
      • Anwendung von Patches
      • Perspektivisch: Template fuer Patches?
    • Empty String Problem
  • Generatorfeatures
    • Neuer validate Command
      • Als GIT hook?
      • Abhängig von git (-> opensource? github?)
    • Version command hat changelog Argument
    • Siehe Topics für mehr
  • Katalog & GDPR
    • Systeme haben jetzt nur opt-in "Involved Persons" aufgrund von GDPR
    • Keine Änderung durch einen Umzug auf Github (auch Aggregation ist nach neuem Gesetz nicht moeglich)
    • => Option: Nachfrage an Developer schicken ist eine Option

Template Änderungen (Robert)

  • Merging von Famula Branch in den Master
  • Wichtig, dass es vor YAML Umstellung passiert
  • Template Hirachie
  • Testing
    • Werden per default ausgeführt (opt-out nötig)
    • Vermeidbar auch über leer setzen von passenden Variablen
    • z.B ci-deploy Modus ist hier eigentlich für andere Anwendungsfaelle
      • Testing dauert zu lange für gewisse Situationen (z.B Studierende)
      • Besodners bei 3rd-party software (tests sind nicht relevant)
        • Mechanismus nötig um diesen eine Sonderrolle zu geben (keine tests, kein CI-Modus)
        • Mit dem Include-Mechanismus könnten auch Variablen überschrieben werden
      • Finden gemeinsamer defaults der verschiedenen Modi
        • Mit Hinsicht auf das neue include feature ist der Konsens:
          • => Testen wird default
          • => Vorerst manuelle Deaktivierung in den Distributionen
          • => Perspektivisch via "external" flag sind die Tests deaktivierbar

Umstellung von Projekten auf Github template

  • Script vorhanden für die Umstellung
  • Geringere Transparenz bzgl. der git URL
  • Script wird auch auf Einzelprojekte anwendbar gemacht
  • => Anwenden vorerst nur für github, dann bald auch für code.cor-lab, projects.cit-ec, etc.

Include of Distros

  • Wie genau soll der include Mechanismus funktionieren (insb. mit Perspektive auf Variablen)?
  • Abhängig von der Qualität der Distributionen und genutzter Variablen
  • Keine Variablen übernehmen VS. alle Variablen übernehmen
  • Scoping der Variablen? Globale Variablen (z.B. im Rezept) VS. lokale Variablen (z.B. im Projekt)
  • Vorschlage der Diskussion
    • Regulierung via @next-value
    • Inherit Zeile hat auch Parameteroption zur Auswahl der zu nutzenden Variablen
    • Neue Konzepte Projektlisten und Metapaketen (analog zu anderem packaging tools)
    • Neues Konzep eines Stacks
    • In Distributionen eine semantische Trennung zwischen Variablen (überschreibbar vs nicht überschreibbar )
    • Nicht überschreibbar Variablen einführen
  • => Stacks; Explizit mit gleichen Mechanismen + gute Beispiele
  • => inherit -> include

Merging different versions of recipes

  • projects.cit-ec ist immer private
  • Liste von Duplikaten+aufräumen
  • Personenfrage, wer macht die Maintenance?
  • Option: Unterordner? Organisierung der files

Feature-Requests

  • Freezing of Versions (reproducibility)
    • Eintragen den Version/Hash in dem Projectfile eher nervig
      • Relevant bei der Fixierung einer Distributionsversion
      • Dennoch explizit und gewisse Dokumentation
      • Neue Alternative: Version Pattern angeben die als Tags/Branches auftauchen sollen
      • => Direkt Commit Hash in .dist erlauben
      • => Generator erzeugt einen Job, der diese Aufgabe übernimmt und eine Liste der Projekte inkl. Hash erzeugt (via rest/groovy Skript)
  • Ros package dependency bug
    • Verschoben auf den kommenden Termin
  • Weitere verschoben auf den kommenden Termin
  • IF Konstrukt
    • Frage der Syntax - Implementierungsaufwand absehbar
    • Implementierung als Funktion
    • In WIP-docker ist die Syntax vorhanden und kann getestet werden, nachdem IF hinzugefügt ist

Dokumentationsstand

  • Verschoben auf den kommenden Termin

CITK -> Echtes Opensource Projekt

  • Verschoben auf den kommenden Termin