PCM Development/Minutes Developer Meeting 20151104

Teilnehmer

Release Termin:
- Sebastian: Noch während der Palladio Days
- Falls noch was ist können wir ein Service Release machen
JIRA noch mal durchschauen und entsprechend Sachen anpassen, die nicht fürs 4.0 Release gefixt werden auf 4.x setzen
Release Datum:
- Latest wird gebaut und dann getaggt und dann ist es im wesentlichen fertig: Datum 04.11.
- Releaseverantwortlicher (Michael) updated die Homepage und schreibt die News E-Mail; Datum: 5.11
Sollte es nach dem Release Probleme geben erstellen wir ein Service Release 4.0x oder 4.x

Bugs an SimuCom:
- Problem: Wir haben keinen der SimuCom pflegt bzw. sich damit auskennt
- bis dahin werden die Bugs an Michael Langhammer zugewiesen

Bugs:
- 238 wurde von Philipp geschlossen —> wenn der Fehler wieder auftritt kann der Bug erneut geöffnet werden
265 Anne fragen, ob das gefixt ist

Nachtragen im JIRA:
- 369: won’t fix (erledigt)
- 383: Add Subtask: in Experiment Automation: Adapter müssen an neuen Konfigurationsparameter angepasst werden
TODO:
- Minimum Examples aus dem SVN löschen

Bei der ConnectorCompletion kann es sein, dass einige Simulatoren nicht funktionieren
- Bei EventSim funktioniert es momentan z.B. nicht
Bug: 375 Subsysteme können nicht direkt allokiert werden

sieht ziemlich cool aus
wenn wir das verwenden wollen müssen wir das aktuelle Wiki bzw. die Palladio Unterseiten migrieren
- vielleicht können wir dazu die alten Mediawiki Skripte noch mal verwenden
Vorteile
- jeder der einen Account beim Jira hat automatisch Zugriff
- speziell für Palladio
- Hat eine FAQ
Nachteile
- Semanitkfunktion zu Tools würde verloren gehen, aber: es gehen Formulare; TODO: man müsste mal testen ob man die Formulare ausreichen
Aufgaben wenn wir es nutzen wollen:
- Aufräumen des aktuellen Wikis
- Migrationsskript erstellen bzw. finden
- Verantwortlicher sollte bestimmt werden. Michael fragt Sebastian und Misha
generelle Entscheidung:
- es ist einen Versuch wert, wir müssen aber einen verantwortlichen finden

Make throughput characterization of network resources optional. Reason: Throughput cannot be set to a default value that has no effect, such as latency (which can be set to 0 and then has no effect). Currently, the only way to disable throughput simulation in SimuCom is to not use BYTESIZE characterizations (I think). Alternative: Change simulation back and only simulate throughput with completions. Another alternative: Add a checkbox to the simulation, but that is not useful.
- von Anne
- hängt zusammen mit Completion/Network Simulation
- throughput caracterisation wäre 0/1 bzw. infinity Wert im Metamodel
- Idee: vorhandenen throughput auf “notset” setzen was dazu führt, dass es die Simulatoren nicht repräsentieren —> konvertieren in feature request

Clarification of behavior when multiple resource demands are attached to the same InternalAction. Currently this is (mostly?) handled by executing the demands sequentially. It may be helpful to have a specialized Action where all demands are to be executed in parallel, i.e. to have concurrent CPU and I/O demands. - Henning
- InternalAction sollte einen Angabe haben ob sie parallel oder sequential abgearbeitet werden (default sollte sequential ist —> momentan ist es sequential)
- Einigung:
  - Tasks für die Änderung anlegen, der weitere Subtasks nach sich ziehen wird (z.B. Anpassung der Simulatoren)

ResourceRequiredDelegationRole und RequiredResourceDelegationRole
- es sollte nur RequiredResourceDelegationRole geben

wurde im letzten Concall besprochen
Probleme:
- unklar (für externe) was unter welchem Projekt gepflegt wird
- JIRA auslegen wie die Update Seite
allgemein gute Idee; die vorgeschlagene Strukturieren passt ganz gut
man könnte nochmal über die JIRA Aufteilung reden
evtl. Nachteile:
- könnte Probleme beim Release geben, aber man kann eh alles einzeln Releasen
- vielleicht gibt es ein Tool/eine Sicht die anzeigt ob es möglich ist die Issues den dann neuen Projekten zuzuordnen
  - Idee hierfür: Die Issues sind ja schon den Komponenten zugeordnet, wenn wir die umziehen könnten, dann könnten wir die Zuordnung (halb-)automatisch machen
Beschluss: wir machen es wenn sich der freiwillige (Stephan) bereiterklärt das zu machen (was er getan hat)

current status
- GMF Editoren werden nicht mehr weiterentwickelt
- GMF Editoren sind schwer zu erweiteren
migration to Sirius
- current status
  - Sebastian hat schon Editoren mit Sirius gemacht/machen lassen
  - siehe Wikiseite zu Sirius Editoren
  - am weitesten ist der System Editor; der funktioniert schon ziemlich gut
  - der ResourceEnv. Editor funktioniert auch schon recht gut und berücksichtigt auch die Profile
- die Erweiterung von Sirius Editoren ist sehr einfach
- Komplette Migration erst wenn alle Editoren erstellt wurden
workflow ist mit Sirius etwas anders, aber das ist in ganz EMF mittlerweile überall der Fall (da auch für Ecore Editoren Sirius verwendet wird)
Idee: Nach dem Release die Umstellung testen; bis nächstes Jahr sollte die Umstellung fertig sein
- Nächste Schritte: Mit Misha reden und fragen wie weit Michael Junker gekommen ist
- sofort aber spätestens sobald alle Editoren fertig sind sollten die Palladio Developer diese verwenden um evtl.

Erik hat Studi der das versucht hat über eine M2M Transformation zu realisieren
- Edapt könnte man sich anschauen, aber Erik wird sich sicherlich etwas dabei gedacht haben warum wir das mit M2M Transformation realisieren sollten
ist eine relevante Arbeit für PCM insbesondere für Palladio User

wenn wir GIT verwenden, dann sollten wir pro Update Site Feature ein GIT machen
Eclipse Integration für GIT ist gewöhnungsbedürftig
GUI Unterstützung ist nicht wirklich gut (gilt für alle Plattformen)
das Build System muss umgestellt werden
Reclipse ist schon auf GIT umgestellt
wo dann hosten?
- wir sollten das dann auf github hosten
- Atlassian hat ein github “für zuhause” —> dann könnten wir es bei uns hosten
- Vorteil github: höhere öffentliche Sichtbarkeit
Einen Backup Job sollten wir dann aber noch laufen lassen
JIRA Integration sollte auch funktionieren (sollte aber gehen)
beim umziehen wird auch die History (hoffentlich) mit umgezogen
auch hier benötigt einen Verantwortlichen und einen Plan:
- Idee: QAL umziehen auf github, dann hat man schon mal einen Teil
- Wir sollten einen SHK oder einen HiWi finden der sich das zumindest mal anschaut
langfristiges Ziel:
- Komponenten im JIRA migrieren wenn es akkut ist, d.h. bevor man anfängt für ein Projekt zu entwickeln