Followup Developer Unconference Meeting:
Meeting Join URL: https://zoom.us/j/407090817
Meeting Date/Time: 25/07/2019 1:00pm (UTC/GMT)
Meeting cancelled this month.
Due to:
- No current agenda items, until TSC have seen up-to-date document.
- Waiting on response in regards to communicating document to TSC.
Action Points:
Gareth Roper to schedule monthly unmeeting. The last Thursday of every month.
Gareth Roper to clean up comments from meeting, shown below. See below point.
Gareth Roper to create document for TSC. Document draft has been created, finialising still.
Meeting Date/Time: 27/06/2019 1:00pm (UTC/GMT)
Agenda:
- Welcome. Covered
- Go over previously discussed topics. Covered
- Review topics that were not discussed. Covered
- Add any additional topics. Covered
- Decide on how to proceed with the Developer Unconference. Covered
Action Points:
Gareth Roper to schedule monthly unmeeting.
Gareth Roper to clean up comments from meeting, shown below.
Gareth Roper to create document for TSC.
Meeting at DDF June 2019
Date: 2019-06-12
Time: 08:00 - 10:00 UTC
Discussed Topics:
1: Setting up developers ENV - making it easy ....ONAP
...
______________________________________________________________
- Test ENVs -- "Hello world"ing
Later Discussion-
- Documentation -- Developer focused
Tagging documents. Especially related to the old documentation.
Tagging each document with a specific release.
Checking old tags.
*Readmes in GIT repositories. Projects missing readmes and some are out of date.
CSIT documentation needs to be improved.
RST format
Old / out of date docs
Wiki maintenance
- Code Review Processes
Variety of these across projects and contributors contributors
See this JIRA
| Jira | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Having multiple colleagues in the same component/project leads to easier reviewing but potentiall causes rubber stamp
A committer will need to check the review before a merge, this should help to alleviate the issue. However there have been situations in the past where this has not stopped the issue.
CSIT suites used as part of the review process, has been discussed previously. Resource issues may be a blocker on this.
CSIT tests should be locally executed before a review is created.
Sonar analysis before the code review. Without analysis can cause issues after merge.
Running these tests can avoid multiple time wasting issues down the line.
Large code dumps make it extremely difficult to review for people not working on the project.
- Sonar Q / Check style
reviewer can not see code coverage easily
...
build in checks - samsung proposal
Sonar analysis before the code review. Without analysis can cause issues after merge.
Who has the access to define the sonar validations?
Need to see that the commit doesnt introduce any issues before it is committed.
Probably LFIT release engineering have the ability to change the thresholds.
Threshold values needs to be a TSC decision.
Not build breaking as changing them could be difficult.
- Kotlin language - bringing it in
Further discussion
- Reflecting Jira ticket status in Gerrit
Automated Jira status change based on Gerrit status. (When review is added should change the Jira status?)
Should not automatically close tickets, but maybe a different status.
A lot of tasks are not in the closed status.
Possibly every Jira task equals 1 gerrit review. Requires small Jira tasks.
Possibly use the "Submitted" or "Delivered" status after review created/reviewed.
- Project developed in a company - and then big code delivery to ONAP
Don't know what business func is being contributed across multiple sub projects. Suddenly big chunks of code appear - community not aware of all activity
Large code dumps make it extremely difficult to review for people not working on the project.
Seed code into new project is more understandable.
Large amounts of code added to existing project can be extremely "disrespectful" due to the ripple effects and consequences down the line.
Situations of 1 person committing and merging the code also.
Multiple experiences of this issue.
Possibly require documentation before a commit is merged, will only mitigate the issue.
Should there be a standard for maximum size of commits, and should you need to exceed it what are the guidelines.
Effectively not reviewed as its near impossible to fully review large code dumps.
Sonar and CSIT testing before review may only mitigate problems, not solve them.
A solution for this needs to be investigated.
No reason why this cant be applied to a new project not just existing ones.
- Bring Pairwise testing early - CSIT tests
CSIT suites used as part of the review process, has been discussed previously. Resource issues may be a blocker on this.
CSIT tests should be locally executed before a review is created.
CSIT documentation needs to be improved.
Pairwise = Testing multiple components together.
CSIT does simulate a lot of ONAP, so can miss osme issues
Possibly no things are simulated, test a fully working system. (assuming no resource issues)
A large amount of time can be spent getting the ONAP and the CSIT tests to run effectively.
- Different deployments platforms for testing - OOM and cloudify makes testing difficult (DCAE)
further discussion
Documentation will help here ofcourse
OOM difficult to use for beginner
- Do we have a miniature version of DMaap for testing - its very large
Further discussion
Documentation
- Policy testing wrote their own simulator --- are simulators a solution
Something has to be simulated, a full lab test can cause resource issue
Investigate solution for full lab test.
Robot and CSIT tests run daily, 2 completely separate repos/code bases. Portal component just copied the robot tests across.
In practice no one has reused the same test code for both code, it has been duplicated and adjusted.
Should reduce as much as possible, no best practices currently or examples, apart from common library which doesn't contain much yet.
Can help to reduce after commit errors
Testing negative situations with simulators is much easier than testing with a full ONAP. Simulators will be needed.
You will need to write specifc test code for a full ONAP. Less control and ability.
Verfied in the use case testing, but this will only be positive testing.
We should have both simulators and full ONAPs for testing, best of both worlds.
- Common library for JSON POJO sims / mocks. An API library for managing common events between systems.
A common library would eliminate time wasted.
How do we document this, how to find correct documentation etc.
Further Topics:
Check Style and Formatting Standardization
Check style is extremely different for different projects.
Many projects that have no checkstyles example: AAF has no code standard
Should be identical for all sub projects of onap.
Will help across the board, reviews further documentation.
An ONAP checkstyle should be standardized.
When you import the checkstyle template into Ecilpse it seems to change.
Running the checkstyle through an Maven build appears to be more accurate than through importing to Eclipse/Intellij.
Formatting checked into A&AI. Instructions to add to Eclipse available.
Should have a centralised area for checkstyle and formatting.
Should we be updating our checkstyle when Google adds features et. to the checkstyle template that ONAP uses a modified version of.