# Summary of May 2022 meetup

## Stricter Eiffel

## Methods of promoting Eiffel to a wider audience

## Acting on event sequences

Because of Eiffel's nature of linking events, a simple event trigger that acts on a single event often isn't enough. Use cases:

- Trigger builds on series of events.
- Lead time calculations and KPIs.
- Grouping activities.
- Find data in linked events (and avoid convenience-driven custom data).

What would a generic way of expressing such sequences look like? Is Eiffel Intelligence good enough or should we build something else?

We explored the following example in a made-up language that should trigger when we get a finished testcase that was run for a Debian package artifact that links to a CD and has received a verdict via a CLM:

TCF -> TCT -> ArtC[data.identity~"^pkg:deb/"] <- CLM, -> CD

We outlined an algorithm that should make an implementation of an interpreter for such a language feasible to implement.

## Supply chain security

## Deployment events
Using the [DORA metrics](https://www.devops-research.com/quickcheck.html) as a starting point we explored what kinds of events we need to be able to compute lead time and deployment frequency metrics using Eiffel. Key questions and outcomes:

- Should the deployment be wrapped in an activity or a separate set of Triggered/Started/Finished events? We don't do that for builds but we do it for tests.
- The input for a deployment is an artifact (or a composition of artifacts), a deployment configuration (possibly part of the artifact composition) and some kind of environment reference.
- When is a deployment done, considering canaries and other forms of gradual rollouts?
- What makes a deployment successful?

## New link type for ArtC to describe relationships to other artifacts

## Activity event linking

Walkthrough of the draft PR ([github.com/eiffel-community/eiffel#287](https://github.com/eiffel-community/eiffel/pull/287)) that introduces the PRECURSOR link type as a way of describing sequences of activites that occur in an orchestrated pipeline where CAUSE links are hard to apply.

## Source change events

A thorough walkthrough of [github.com/eiffel-community/eiffel#261](https://github.com/eiffel-community/eiffel/issues/261) and the new source change events described there. Apparently Ericsson and Axis work in git in slightly different ways, which explains why the SCC and SCS look the way they do and why Axis folks aren't too happy with it. No flaws with the proposal were found but we should document a few more scenarios, e.g. what happens if a new commit is created as part of the merge operation.

## Improve documentation structure