Talking with Phil about this, it seems like it was mostly bad communication, maybe not as bad a policy as we first thought.
On TSC-89, I do believe that the issue there is one much more of a poor job on my and Casey's part to understand what was/is going on within LF's IT-Infra team and properly communicate it to ODL rather than forced mandates coming down from on high at the LF with no consideration for the communities/customers we serve. I have been investigating this issue with LF IT and I now understand what's going on. As I expected, it is not nearly as heinous as it was presented last week at the TSC meeting.
Paraphrasing Steve Ira, Director of LF IT:
- There is no mandate for ODL to move off of mailman
- LF IT is moving to manages services for parts of it's infrastructure tools it supplies... wordpress, JIRA, and others where there isn't much value add from LF.
- LF IT is moving out of Oregon State Univ.'s Open Source Lab (OSU-OSL). They are not reliable enough for our projects. They go down, or worse yet, get hit by a vulnerability, and it is badness for our projects. LF's mailman instances are run out of OSU-OSL, and we are moving out of there by June.
- LF-IT will manage locally groups.io mail service for those projects that want it. It has been very popular with the vast majority of LF project to whom it has been shown and deployed.
- If (since) ODL doesn't want to move to groups.io, LF-IT will keep our instance of mailman running in OSU-OSL past June, if needed and will be looking for another managed-mailman provider to provide that service to the ODL community longer term
- ODL is welcome to stay on mailman as long as it likes.
So, I believe that particular issue is a non-issue. If there are other tops-down behavior that the ODL TSC perceives and wants to raise to the TAC, please go ahead and do so. For this issue in particular though, again, my apologies for the poor handling of the dialog by Casey and myself.
I'm working with Casey so that we don't come to the ODL community with these types of changes, or suggested changes in the future without better understanding the reasoning for the change and the options/alternative available to the project.