Location

FZI Forschungszentrum Informatik, Haid-und-Neu-Str. 10–14, Karlsruhe
How to get there

Time

12:00 Lunch
13:30-?18:00 Meeting

Participants

Participants (please register: http://www.performance-symposium.org/2017/registration/):

Andre van Hoorn
Thomas F. Düllmann
Christian Wulf
Christian Zirkelbach
Marc Adolf
Armin Möbius
Teerat Pitakrat
Holger Knoche
Reiner Jung (added my comments below, won't participate)

Photos

Agenda

(15) Slides for Short Kieker Update on Thu morning

Discuss draft

(10) Organization

KIEKER-1641 - Getting issue details... STATUS
- Reiner Jung is in favor of cutting our Sourceforge ties. The site is horrible and keeping them for mailing lists makes no sense at all.
- Migrate release KIEKER-1661 - Getting issue details... STATUS
- Replace mailing lists by DFN-provided list KIEKER-1608 - Getting issue details... STATUS

(10) Work distribution for students (hiwi, projects, theses)

Mark tasks with a label, like 'hiwi'?

(TD) I currently use 'KiekerHiwi'

key	summary	type	created	updated	due	assignee	reporter	priority	status	resolution

Loading...

Refresh

Mark tasks for theses with "thesis"

key	summary	type	created	updated	due	assignee	reporter	priority	status	resolution

Loading...

Refresh

(15) PMD, Checkstyle

Christian Wulf (Unlicensed) Presents Eclipse Plugin that allows the use of custom rules in PMD — later maybe also Checkstyle
Holger Knoche developed a tool to generate CSV reports for rendering the report files from Checkstyle — should be easy to adopt to PMD, FindBugs. Would replace the legacy HTML report.

(30) Kieker Releases

1.14
- Features
  - closed 1.14 tickets
  - main: TeeTime
  - Misc (tickets labeled with 1.14)
- First TeeTime integration
  - Reiner Jung We should create a ticket listing all tasks to be performed for the integration and the deprecation of old stuff. It might not be possible to have all this done by 1.14. However, we should define all tasks and then select which we want to have in 1.14. And we must be reasonable in our goal, as Christian Wulf (Unlicensed) will most likely be no longer available after finishing his PhD.
    - Action items
      - Merge master back into respective integration branch to obtain a Jenkinsfile to trigger the creation of the pipeline
      - Merge branch back to master
      - Document the use of the TeeTime-based analysis
- Release date
  - Reiner Jung as release creation is still time consuming (maybe we should work on that), I recommend to have two releases. The best idea would be to align the two releases per year with time of lower workload, i.e., towards the end of the seminar free periods of each semester, but before the exams weeks.
  - Targeted release date January 31, 2018 (assuming feature freeze ~end of December)
2.0
- Target release date
  - Regular schedule, i.e., October 2018
- Features
  - nice to have: diagnoseIT
- API changes
  - KIEKER-1647 - Getting issue details... STATUS
    - Reiner Jung as the reporter of this ticket, I recommend removing the interface methods regardless our mistake.
  - Writer/reader ("technology-based packaging") Holger Knoche
  - Results of diagnoseIT
    - Reiner Jung we should consider which results should go into the main source tree, i.e., identify what is framework and what are separate projects. It might even be a good idea to move tools in separate git repositories. At least we should provide them as separate packages (we could use the same gradle mechanism iObserve uses for producing bundles see also KIEKER-1634 - Getting issue details... STATUS ).
"Misc": Next dev meeting: assign Tickets marked with 1.14 to either 1.14 or 2.0
DONE: Trace Diagnosis UI
- Decoupled from Kieker releases. Already integrated into the infrastructure (Atlassian, GitHub)

(45) Development process

Revisit/document development workflow (from feature to pull request)
- older branches need a Jenkinsfile to get a Jenkins pipeline
Avoid API breaks and architecture-critic/breaking changes; How to avoid major architecture degradation? (see, e.g., trend in nightly benchmarks)
- Reviews for architecture-critic changes that cannot be analyzed automatically
  - We cannot enforce it due to a missing integration between Jira and GitHub.
  - We could add a field to tickets "requires-review" and modify the workflow
  - Reviewers can be assigned for a pull request.
    - That's what we will do now
    - Potentially in combination with a Jira comment pointing to the pull request and an assignment of the ticket
- Christian Wulf (Unlicensed)'s Dazzle tool to monitor API changes from a baseline version to the current one KIEKER-1662 - Getting issue details... STATUS
Presentation of workflows for issue types
Definition of epics (improve release creation, improve usability, ...)
- We see an epic as a long-term activity/goal
- Everybody agrees that it makes sense; let's do it
Automation of release creation
- KIEKER-1634 - Getting issue details... STATUS
- KIEKER-1616 - Getting issue details... STATUS
- KIEKER-1615 - Getting issue details... STATUS
Performance degradation
How to handle API changes
- Important part as the correct procedure to first deprecate and then remove (e.g.) a method
- Dazzle would help here to monitor violations
- TODO: document process of API changes
Docker Containers (Build Process)
- Automated Build vs. Custom Pipeline
- Repository Structure

(45) Code organization

Integration tests (split directory, cytrus, docker, )
Pains with Gradle
- Reiner Jung In iObserve we have a solution for external libraries which do not have a proper maven resource or where the version we want to use are no longer available. We use a self constructed maven repository stored in a git repository for safekeeping. We could use the principles used to build the iObserve maven repo to remove all external libraries from the Kieker source tree and store them externally. Therefore, we could use the normal dependency mechanism of gradle and get rid of large portion of the hacked and stitched together dependency mechanism.
- Reiner Jung Together with the idea of producing bundles for all tools (see KIEKER-1634 - Getting issue details... STATUS ) this could be very easy. I added a typical tool example in the ticket.
- Reiner Jung One additional idea to manage library dependencies can be through jitpack (in contrast to the iObserve method). However, it requires that the project in question is available via github. It has also the downside that we cannot control the Java version on these libraries. However, we could fork these libraries and then control them, but this requires us to maintain these forks and I am not sure we have the manpower to do this.
Separate Gradle projects for technologies (with reader, writer, tests), e.g., kafka etc.
KIEKER-1463 - Getting issue details... STATUS

(20) Documentation

Web site KIEKER-1657 - Getting issue details... STATUS
User guide (migrate to html)

(15) What about Joint research + publications?

(30) All Tickets marked for the SSP17

key	summary	type	created	updated	due	assignee	reporter	priority	status	resolution

Loading...

Refresh

Browser not supported