8:45 p.m.
Attending:
Johan, Ivan, Rainer, Heather, Christos, Scott
Regrets:
Roland
https://bluejeans.com/163562895 <https://bluejeans.com/163562895?src=join_info>
Notes:
1. Governance update
a. Commons Conservancy - now officially under the care and feeding of the Commons
Conservancy
b. Note Well and licensing by repository and/or license in each file - this sounds
like an overcomplication. Ivan’s take is that having a license per file is actually not a
good practice, and the open source community is moving away from that. If you are using
files someone else has developed, you usually import the whole project and not just
individual files. Another problem - licensing a project is more than code files. It’s also
documentation, HTML files, binary files, etc. You can’t always add headers to those types
of files. Proposal: have a structure with a single file where you declare the licensing
and copyright for the whole project. All of our projects already have this for the
license, though the attribution/copyright may be different. There may also be different
licenses (apache and 2-clause BSD), and while we prefer apache it is not required. Where
we have the 2-clause BSD, those files should be updated to include that name.
2. Code releases - speed vs stability? Right now, Ivan has to do PR review, making sure
the change fits the general strategy that Satosa (and other projects) have for the future,
and also think about other things like code quality, etc. This is a very big job for one
person. Proposal - flag something that works but that could use some improvement.
Alternatively - allow for more breaking changes. Also worth noting that there has been a
lot of code changes (many PRs accepted) but not an actual code release.
Open question: would there be code releases with the ugly code in there? In eduTEAMS they
do allow that - as long as it works, it can be released. But they note what needs to be
cleaned up later. (The downside: accruing technical debt fairly quickly)
Scott points out that the code has greatly improved since Ivan started. But he still has
functionality that is needed, it exists in an older PR, how should he handle this? Also,
it’s hard to work with clients when there aren’t regular releases (that just need “pip
install” to get working code). Ivan has the concern about introducing breaking changes as
PRs are accepted at one stage, but then have to be redone and introduce breaking changes
later. Are we ok with that?
a. Resources (do we have enough if we use them well? If not, what are we asking the
idpy Board for?)
Scott asks: Is there enough effort outside of eduTEAMS for Satosa? Right now, eduTEAMS
both funds Ivan (as does SUNET) and eduTEAMS uses Satosa. If eduTEAMS dropped Satosa, Ivan
would still need to dedicate time to Satosa and balance that work. eduTEAMS is also trying
to train more developers to be good enough to push their code back upstream, though they
are not quite there yet. Final answer: Ivan should not get hit by a bus, and we can not
use additional resources effectively at this time.
3. GitHub review - discussed after note taker left
a. pySAML2 - https://github.com/IdentityPython/pysaml2
<https://github.com/IdentityPython/pysaml2>
b. Satosa - https://github.com/IdentityPython/SATOSA
<https://github.com/IdentityPython/SATOSA>
c. pyFF - https://github.com/IdentityPython/pyFF
<https://github.com/IdentityPython/pyFF>
d. ...
4. AOB
Next call: 28 May 2019 (HF unavailable)