You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »


Followup Developer Unconference Meeting:

New Meeting Link: https://zoom.us/j/644920226

Meeting Time: 20/06/2019 2:00pm (GMT +1)




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

        The Good  :   We have a lot of people out there that can do this.

                            Whats there means people can get going.

        The Bad  :  

                       - For new people coming in (new company) it is difficult - they need to do it themselves

                       - Multiple projects setup together is difficult - nature of a big system.

                       - Duplication of places issues are recorded.

        The things we can Improve : 

                      - Not all projects have readmes - Each project should have one.

                      - Each project should have an owner - The PTL is the owner 

                      - This info is in info.YML - could do this at a per module level - or down to the level the project thinks this is appropriate 

                      - Need to keep this updated as people move

                      - Suggestion - Lazy Dog - "Repeated task documented" - question is where to put them -

                      - Lazy dog per project / by release    --  tricky to keep up to date.

                          - e.g. sharp title - "Error Code title" + workaround (NOTE: Jira will also record it.

2: Tutorial is there - but its out of date.....could there be better tutorials developed.

    The Good:  Generally existing people can help new people coming    

    The Bad: 

                      - Tutorials are "Woeful"

                      - Hard to get started - but once up and running it is OK.        

    The things we can Improve : "How does it breath".

                       - We should make a tutorial for developers joining ONAP - 

                       - We need to reference the various info tools, - Owner,  info.YML, lazy dogs etc. Top level info to get started

                       - We could archive old tutorials.

                       - Important that new people reach out, start participating, and that existing people will support new people ---- big projects can spread on-boarding support around

                            - Common  gain if more people working on similar stuff.

                       - This is less work than tutorials on everything  

                       - Work on a getting started page - can update existing one.

                       - Communication policy

                            - Rocket chat - not widely used by every user

                        - Discuss list is the official comms forum

                        - Weekly meeting is primary focus

                        - Component Tutorials for new developers :

                             - These are needed, and need to be updated periodically

                Message to PTLs that this needs some capacity 


3: Project Scheduling + getting adequate coding time

    The good :

         - ElAlto is helping - giving breathing space 

    The Bad :

        - Dublin development window was very tight

        - Late Epic freeze - short coding window

    Improvements :

        - M0 needs to be M0.

        - Be formal about Epics closed at M0 to ensure development time

            

4: Jira - marking them easy for beginners

List of people you can contact in regards to specific components: 

https://wiki.onap.org/display/DW/Resources+and+Repositories#ResourcesandRepositories-ActiveandAvailableInventory



This is gold standard badging: https://bestpractices.coreinfrastructure.org/en/projects/1197?criteria_level=2#changecontrol

- We can move it earlier

- Common labeling convention would help.


5: Unit testing

    The Good:

         - There are some best practices

    The Bad:

         - There are a lot of bad tests out there

    Improvements : 

        - Mutation tests - can identify in effective tests

        - Coverage on new code - expectation is new code always has effective coverage. This is not enforced in tools, but could be turned on.

          


Next steps

    Book a slot a TSC and feedback  a summary of this meeting to them.

    Do as a one off for now. & feedback to TSC and PDLs. ACTION : @Gareth Roper to call next meeting


    Consider Schedule a monthly "Developers UnMeeting" to follow up on this.

        Monthly feedback to TSC and PTLs

    Informal for now. 



______________________________________________________________

Topics identified in the meeting and for further discussion

______________________________________________________________

Test ENVs  --  "Hello world"ing 


Documentation -- Developer focused 

        RST format

        Old / out of date docs

        Wiki maintenance


Code Review Processes

        Variety of these across projects and contributors

       See this JIRA











        

Sonar Q / Check style

        reviewer can not see code coverage easily

        enforcement 

        build in checks - samsung proposal


Kotlin language - bringing it in


Reflecting Jira ticket status in Gerrit


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

        

Bring Pairwise testing early - CSIT tests


Different deployments platforms for testing  - OOM and cloudify makes testing difficult (DCAE)


Do we have a miniature version of DMaap for testing - its very large


Policy testing wrote their own simulator ---   are simulators a solution


Common library for JSON POJO sims / mocks. An API library for managing common events between systems.





  • No labels