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/):
Photos
Agenda
(15) Slides for Short Kieker Update on Thu morning
(10) Organization
- 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
- Replace mailing lists by DFN-provided list
(10) Work distribution for students (hiwi, projects, theses)
- Mark tasks with a label, like 'hiwi'?
- (TD) I currently use 'KiekerHiwi'
- Mark tasks for theses with "thesis"
(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
- API changes
- 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
).
- "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
- 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
- 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 ) 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.
(20) Documentation
- Web site
- User guide (migrate to html)
(15) What about Joint research + publications?
(30) All Tickets marked for the SSP17