-
Notifications
You must be signed in to change notification settings - Fork 77
Roadmap Meetings
This meeting was the kickoff meeting where the dev team discussed some of the following topics:
- The vision of releasing software
- Development Workflow
- Review process for Technical Contributions
- Regression and Unit Testing, Code Coverage
- Documentation, QAQC Plan
- Packaging and Release Schedules
- Meeting Schedules
- @bemcdonnell,
- @michaeltryby,
- @samhatchett,
- @goanpeca,
- @lrntct,
- @aerispaha,
- @fmyers,
- @abhiramm7,
- @rkertesz
That was a great first discussion of many to come! Thanks for being part of a magnificently magnetic community of developers! This project looks forward to working with you all to support a strong future of SWMM, PySWMM and EPANET. The conversation was packed full of valuable perspective and experience. It’s more than just lines of code… it’s the community, it’s the process, it’s the motivation, it’s the value, it’s the enriching feeling that your code helps others… and what is code without users?
The general flow of our discussion entailed talking through the process of adding code and all the steps it would take to provide a clean distribution package for the users. There is opportunity here to automate a QAQC workflow to provide assurance that the code is performing as well as the benchmarks.
- Rate All issues (Easy/Hard)
- Add Documentation
- Example of how to fix a basic issue step by step
- Add clear build instructions and YouTube Videos if someone wants to take this on
This process is generally very common across all dev projects. It generally follows this workflow:
- Raise an issue and give some ideas. Maybe it is a bug fix, maybe it is a new feature. Let's discuss it before going deep into coding
- Fork to your repo, Branch, and start coding!
- Commit your work to your Fork. As unit testing comes online it will be appreciated if you provide new unit tests for your code. This is more API focused at the moment.
- Submit a pull request. In the comments, reference the issue you are closing (
Closes #x). If you broke SWMM, the CI Servers tests will tell you. Ideally all lights should be green when your work is ready to merge. ;-) There are exceptions to this rule - The community might provide feedback or accept as-is
- Agree to the the Contributors License Agreement (CLAHUB)
- After approval, merge the code!
- Update Documentation. It is best to checkout the
gh-pagesbranch into a git work tree (in the SWMM folder rungit worktree add -f ./gh-pages gh-pages). This step requires Doxygen. Thedocs/Doxyfileis setup to build the SWMM docs and place them in the./gh-pagesfolder. - Repeat!
This discussion was surrounding the latest work by @lrntct. These are Hydraulic Network to 2-d coupling functions. For these types of projects, maybe longer discussions will take place in the Issues page. Some journal article references will also be valuable. As new code comes into the project, there is opportunity to setup unit tests on the new functionality. In cases, it may be beneficial to have other established members of the stormwater community provide feedback.
SWMM (and EPANET) have been configured with a large batch of regression tests. These tests iterate over the Binary Output and Text Report files, item-by-item and line-by-line, respectively. As of today, SWMM is not Unit testable since the data model is not conducive to it. The API, however, will be have unit tests as this project works toward selecting a technology and unit testing goal. The project seems to be heading down the path of using boost and ctest (with CMAKE).
Code Coverage was also discussed. This will reveal to what extent the various functions are called during the tests.
In order for this project to catch on well, good documentation is a great thing to have. As of writing these meeting notes, the docs are now available for the current API SWMM-Docs. We should raise some issues for people to add some examples. We need to document the API, new features, and new fundamental equations. We discussed converting the reference manuals to a digital living format. Could be a great task if some would want to take this on!
The project will benefit from a continued good relationship with USEPA. It will be nice when we can replicate the entire workflow from code to packaging to make it easier for USEPA to accept new community contributions. Automated QAQC documentation with each new release will bring confidence in the toolchain. When we reach this process, we can discuss means and methods.
- Going to setup recurrent meetings
- We are considering recording the meetings and making them available to the general public