Hi all,
the following projects are in, or have been voted into the idpy repository.
OICRP
oiccli
oicsrv
oicmsg
cryptojwt
SATOSA
fedoicmsg
fedoicmsg
satosa_microservices
fedoicrp
fedoiccli
pyop
pyjwkest
satosa-developer
Not yet in git
pyelevel
pysaml
pyff
Out of these,
OICRP
oiccli
oicsrv
oicms,
fedoicmsg
fedoicrp
fedoiccli
Only have Roland as a committer
The others have multiple commiters, as listed in the attached files.
Cheers,
Niels
--
Niels van Dijk Technical Product Manager Trust & Security
Mob: +31 651347657 | Skype: cdr-80 | PGP Key ID: 0xDE7BB2F5
SURFnet BV | PO.Box 19035 | NL-3501 DA Utrecht | The Netherlands
www.surfnet.nlwww.openconext.org
Hello all,
For those of you attending the idpy dev meeting at TIIME, we are up on
the fourth floor. Turn left out of the elevator and walk to the end of
the hallway.
We're going to be flexible with the agenda, as Leif and Roland are stuck
in Sweden (airplane issues). We won't see them until tomorrow.
-Heather
Attendees:
Scott, John, John, Ivan, Roland, Heather
Notes:
Coding style
1. flake8 and SOLID not mutually exclusive?
2. Any objections we should consider against PEP8/flake8?
PEP8 is a start, but need some higher level constraints on things like
variable names.
Google’s style guide builds on top of PEP8.
Perhaps use both? Homework for people to study before TIIME - if you’re
not familiar with any of the above, please look them over and be
prepared to offer an opinion as to whether using PEP*+flake8 and the
Google coding guide should be adopted for idpy projects.
Do we want to rely on autogenerated documentation on the code? Any
guidance we want to apply? Roland is using Sphinx for some of his
projects. Add to discussion at TIIME
Incubator program - Ivan’s proposal vs following the model of one of the
existing incubators
Discuss at TIIME
TIIME agenda
* separate email
AOB
Google would like OIDF to host the libraries Roland is working on. Not
sure what that means with regards to using GitHub to maintain (since
OIDF doesn’t have a GitHub space). Roland would still like the python
libraries in idpy. Not sure what Google would think about that (though
they probably want everything in one space). What if they were offered a
spot on the idpy board? There are many dependencies between them, which
means hosting across different orgs would be unreasonably complicated.
Next meeting @ TIIME (Cancel next week’s call)
Logistics:
Monday, 5 February 2018, Room E, 13:00-17:30
Tuesday, 6 February 2018, Room E, 09:00-12:30, 13:30-16:00 (if needed)
Topics to cover:
* Policy to add/remove projects on idpy.org <http://idpy.org> (see
email 17 January 2018)
* Technical harmonization: project may need dedicated time, and we
need to decide which projects fall under the idpy umbrella,
including discussions on who is the tech lead for each, what the
project maturity levels are, where we need to target refactoring of code
*
o pyOP
o pyOIDC
o OICcli
o OICmsg
o pyJWKEST
o Satosa*
o pySAML
o pyff*
* Consensus call on coding style: PEP8 enforced by flake8, with
Google’s guide offering the additional detail guidance
* Autogenerating documentation - Sphinx
<https://pythonhosted.org/an_example_pypi_project/sphinx.html>? Other?
* Governance and timetable
* Any open pull requests
5 February 2018
13:00-14:00 - Introduction, agenda building
14:00-17:00 - open
17:00-17:30 - review action items from the day
6 February 2018
09:00-10:00 - Governance
10:00-10:30 - agenda building
10:30-12:30 - open
13:30-15:30 - open
15:30-16:00 - review action items from the day
* Satosa and pyff to be covered on day 2
Hi all,
An FYI that I've submitted an unconference proposal to discuss the idpy
project (governance, what projects make up idpy) at TIIME. I suspect we
may want one or two more proposals to specifically discuss Satosa, pyff,
and/or the other projects that (probably) make up idpy.
-Heather
(P.S. I also submitted proposals on RA21 and the REFEDS 2018 workplan.)
Hi all,
Obviously we'll do a fair bit of agenda building on site, but this list
should give us a sense of what we need to cover and how much time we
have. Does anyone have topics they would like to add, or want to propose
a more precisely defined schedule in advance?
-----
Logistics:
Monday, 5 February 2018, Room E, 13:00-17:30
Tuesday, 6 February 2018, Room E, 09:00-12:30, 13:30-16:00 (if needed)
Topics to cover:
* Technical harmonization: project may need dedicated time, and we
need to decide which projects fall under the idpy umbrella,
including discussions on who is the tech lead for each, what the
project maturity levels are, where we need to target refactoring of code
*
o pyOP
o pyOIDC
o OICcli
o OICmsg
o pyJWKEST
o Satosa
o pySAML
o pyff
* governance
* any open pull requests
5 February 2018
13:00-14:00 - Introduction, agenda building
14:00-17:00 - open
17:00-17:30 - review action items from the day
6 February 2018 (maybe have the open time be split between each project?)
09:00-10:00 - Governance
10:00-10:30 - agenda building
10:30-12:30 - open
13:30-15:30 - open
15:30-16:00 - review action items from the day
Hi,
I would like to nominate pyFF, pyXMLSecurity, and pyeleven to be
included under the IdentityPython umbrella and in particular move to the
IdentityPython GitHub account.
The pyFF + SATOSA combination has become critical infrastructure for a
number of research projects that I am working with to leverage federated
identity.
I have dialogued with Leif and he is willing to move the projects under
the IdentityPython umbrella.
Please +1 if you support the motion.
Thanks,
Scott K
There were two ideas related to versioning and release cycles coming out
of today's call:
1. Use semantic versioning for all projects.
2. Every new change (e.g., bug fix, feature enhancement) should be a
separate release.
We can discuss further at the TIIME workshop, but if folks have strong
opinions one way or the other, it would be good to start discussion on
the list. Thoughts? Feel free to [+|-]1
-Heather
Hey everyone,
On 16 January 2018 at 16:00, Ioannis Kakavas <ikakavas at protonmail.com> wrote:
> We touched upon adding more people (Leif) as owners for the pysaml2-dev and
> satosa-dev channels on Slack too
>
That's what we discussed, iirc.
> pysaml2-dev.slack.com
>
>
> satosa-dev.slack.com
>
> Since Leif wasn't a member in either of those, I made Ivan an owner for now.
>
Thanks for that.
I've been on those channels for some time now, and they are both quiet
enough. I would propose to have a single slack channel (idpy.slack.com
maybe?) and have separate channels for each project (that want to have
a channel) - plus the "random" channel for slacking :) , one for
github integration (broadcasting code changes, commits, testing
results), and another for announcements (new releases).
I would also propose to have an idpy-announcements mailing-list, with
only announcements of new project releases, or changes in the
organisation (additions or removals of projects and people) -- that is
strictly announcements, not discussions -- ideally replies should be
ignored by the list.
This would make management and coordination easier across the
different projects and project-communities. It will give an easier
overview of what's happening and will allow external people to
subscribe to only the vital parts that they may care for (project
announcement).
Usually announcements can be posted on a blog or twitter as
yet-another communication channel. This is a process that should be
automated and a trigger will post to all those channels at the same
time.
To close this, this is definitely not a high-priority thing. If we
agree on that, I think we can steadily start moving to that direction.
But, lets discuss it first. Are people comfortable using a single
slack channel? How do project maintainers feel about that? And if we
go forward, can we merge message histories? Should we contact slack
for help with something like that?
Cheers,
--
Ivan c00kiemon5ter Kanakarakis >:3
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)
