2019-05-16 Meeting notes

Date & Location

Thursday 2019/05/16 @ 9 AM PST

Code process (fork -> PR, branch -> PR)?
Ticket process (when to open ticket, ticket type, approvals)?
Testing expectations
When/how patch gets integrated and built
When/how a project should integrate the patch
Release process of hysds components
Discuss existing HySDS API design, best practices, and future development, so we can build automation/operation/reporting tools against APIs instead of directly accessing HySDS components or Elasticsearch.
Find a SIRI intern for fall to help organize/consolidate documentation on Atlassian wiki

Code Process
- What are the current branches and what do they signify?
  - https://nvie.com/posts/a-successful-git-branching-model/
    Yes, use this workflow
    python2 fixes will be hot fixes
    not all hot fixes necessarily make it to develop
PR approvals? Currently can’t request approvers
PUNT – Decision: When to squash
PUNT – Decision: When to rebase
Decision: Should individuals Fork & PR, have a list of committers/mergers, or something else?
- need to identify set of people with “admin” authority on repos
- devs should be able to create feature branches
- circleci should build feature branches
- protect master and develop
- up to dev if they want to fork & PR against feature branch
- PR must have Jira --- should document how git/jira integration works
API Development
- Recommendation to use Domain models so that we can work with the objects across all source code.
- middleware code that abstracts the backend
- API/library for external users (Pele) goes through middleware code

Time	Item	Discussion Lead	Notes

Time	Item	Discussion Lead	Notes
:05-:10	Intro/Previous Actions	@Frank Greguska	Start meeting. Briefly cover previous action items Circle ci can be used across all repos, some repos have it on already: hysds, hysds-dockerfiles, sciflo, prov_es, hysds_commons
:10-:25	Code Process	@Frank Greguska	Discussion on branching/forking workflow that we want to follow. https://nvie.com/posts/a-successful-git-branching-model/ Yes, use this workflow python2 fixes will be hot fixes not all hot fixes necessarily make it to develop
:25-:40	API development	@Lan Dang	Discuss current HySDS APIs, design, and best practices to have more consistency in API design, and possibly consolidate or encourage use of common API for some use cases. https://hysds-core.atlassian.net/wiki/spaces/v3/pages/172785723
:40-:55	How Projects Contribute to Core	@Sujen Shah	Discuss ideas for deploying point releases from core into multiple environments (dev, INT, ops) Developers having access to trigger AMI builds for specific version core and related components. https://hysds-core.atlassian.net/wiki/spaces/v3/pages/27852820
:55	Wrap up	@Frank Greguska	Wrap up meeting, decide on timeframe for next meetup

@Frank Greguska Send out Doodle for next meetup

@Frank Greguska Identify set of people with “admin” authority on repos

@Sujen Shah Document how git/jira integration works. What level of integration do we have enabled and how is it triggered?

We are following the workflow described here: https://nvie.com/posts/a-successful-git-branching-model/
Devs should be able to create feature branches
CircleCI should build feature branches
Master & Develop branches should be protected
Developer’s discretion if they would rather fork & PR or commit directly to a feature branch
Python2 fixes will be hot fixes from python2 branch and should try to be python3 compatible
Hot fixes should have a PR for getting back into develop
There is a need for a middleware abstraction the warrants further discussion