3:43 p.m.
Attending:
Jonas, John, Scott, Heather, Einar, Ivan
Notes:
1. Documentation, versioning and release cycles; coding styles
2. Coding styles and guidelines (e.g.,
https://spaces.internet2.edu/display/COmanage/COmanage+Coding+Style)
Scott would like to see a convergence on these things. For some coding
(e.g., pysaml) it’s hard to get through because of the personal
undocumented conventions use. Having a consistent style would be help.
Suggest starting with PEP 8 is good, but probably not sufficient.
Downside is that some of the code will need to be rewritten. Perhaps a
coding guide per project. It will also take time to review code against
a coding guide. Code with multiple people committing (Satosa and pysaml
initially) will require a style guide. For the other projects with one
person developing, probably less time and effort available to make code
fit the style, but probably less important.
Ivan is to work on a draft proposal for how to accept/reject projects.
One of the things in there is how we evaluate projects, and part of that
is the quality and documentation of code. How willing authors of code
are to adapting their code is also.
Alternatives to PEP 8
* the Google Python Style Guide
(https://google.github.io/styleguide/pyguide.html)
* flake8
* https://en.wikipedia.org/wiki/SOLID_(object-oriented_design
<https://en.wikipedia.org/wiki/SOLID_%28object-oriented_design>)
Having a general structural guide is useful, but also having guidance on
details (e.g., variable names) would be useful.
Need a collaboration editor so we can start drafting something; we can
all write something about what we want to have and would like to see.
Action item: Heather to create a document to start on collaboration
Versioning
Want to use semantic versioning. Not sure pysaml does; it has the same
format, but not following the practices.
Action item: Heather to post to list to get a consensus vote on using
semantic versioning
Release Cycle
Given that most of these projects don’t have full time people on it,
can’t really enforce a standard release cycle. An example of concern is
Satosa, which has had so many changes that production code often has to
run against GitHub instead of an official release version. We don’t want
a new release after every commit, but can we set a standard threshold?
Ivan: Every new feature should be a separate release; no two new
features together. It’s easier to test things. Everything that exposes a
change in API, a bug fix, etc, should be a separate release. This could
result in multiple releases a day. For this to work, the release process
would need to be very streamlined.
Example: if you have three changes (two bug fixes and a new feature),
the bug fixes are each released first in two releases, then the new
feature is released incorporating the earlier releases
Team is willing to try this. Combine this with semantic versioning, and
it should work.
Action item: Heather to take this proposal to the list to see if there’s
consensus.
3. AOB
Next call: January 23 (Heather to solicit agenda items on Friday)