...
- Welcome to Joanna DiPasquale (now as a Community member) and Roger Smith (replacing Declan Fleming), joining Leaders. Looking for ideas for next year for expanding the Community members - continuing to get better representation on the group. There were two Community member slots and only 1 person (Joanna) was nominated.
- Pairing new members to acclimate to Fedora Leaders. Members can add their names to the document and then partner folks up. Pairings haven't been assigned yet, the two columns in the document are just for listing names. Will help to have a smoother onboarding process for new Leaders.
- Fedora Vision and Strategy update (Stefano).
- Subgroups have been created to address different aspects of the Strategy and Vision process. Most groups are well staffed now (thank you for volunteering, everyone). Sub-Groups will self-organize into biweekly meetings and report back to Fedora Leaders. The sub-groups can now begin working together.
- Also the Guiding Principles has been updated, this document summarizes the Strategy and Vision spreadsheet along with a brief Value Proposition.
- We still will want to create a letter to send the the larger Fedora community.
- Great appreciation for everyone in making the time to help move this effort forward!
- Gratitude for Stefano for organizing this and making a commitment to this effort!! And for Maurice as well, for the spreadsheet structure and backbone for our work!
Voting on Policy for long-term support and Supported JVM
These are not new documents, looking for comments and then voting to make them official.
LTS software will require effort to support and maintain
LTS releases will come with the following guarantees: (from the document)
- 3 year period of support
- Ensure stability of the API
- Ensure compatibility with a supported version of the JVM per: Policy - Supported JVM
- Ensure backporting of critical bug fixes and security patches
- Provide documentation and tooling for migration from one LTS to the next
Next steps - an email to the Leadership group looking for support to both of these policies.
- Question: what are the current LTS versions? What is the overlap with the next LTS (if given a three year support window), could it be that at times you have three supported versions, in terms of the window of three years? (ex: two LTS versions and the current release)
- Suggest 4.7 the LTS, b/c 5.0 reflects a significant change
- Suggest that there be overlap, that we don't wait the full three years between LTS versions. But might not be possible to have every time. Will want to consult with Committers and Leadership group about this topic.
- Question: can you estimate the cost of the LTS versions
- Can identify significant costs , budgeting with milestones (tooling, breaking changes, etc)
- Not sure quantifying the costs of the effort is possible in all cases
- Question: Community manager - what are the activities specified, and are the resources needed for this at odds with the needs of the current release. Not wanting to put community manager in an awkward position. Can we put it into the policy that community manager is not responsible for tooling work.
- Need to put a system in place, identifying a person who is known and can pay attention to things such as security patches, and noting these are things that need to be backported to LTS version. Coordinating/helping with the testing and the release. Community volunteer wouldn't be tied to the migration and tooling for one release to the next, but would be focused on making sure LTS versions are secure and patched up over time.
- Will want to create documentation, identify what it entails doing this work, and encouraging the community to participate in project sustainability.
- Question: Is there a notion that the current release (4.7) but is not aligned with the spec would be a long term release?
- It hasn't been decide yet if any version is an LTS. Andrew suggesting 4.7 line be a reasonable candidate for LTS. B/C there is a hump to overcome getting from 4.7 - 5.0. And there is interest in ensuring institutions who might face challenges with migrating to 5.0 have a current version that is LTS.
- Question: Can we make 5.1 the LTS, rather than the 5.0 version? Essentially LTS being one version after the major hump
- Sounds reasonable, this is a conversation that will need to be had, but it is still too early to identify the 5.x release at this early stage. Should be determined on a case by case basis, maybe it is 5.7 not 5.1.
- Want to provide most valuable, providing long term support for releases that the community is using. Separate conversation about 3.8 since there are many people using that still.
- Question: we need to think about the strategy for support. Need to think about the impact and effect of system migration/support. We are challenged by not having a registry. It would be helpful to have a chart of installed versions and where. Process is very good, but we are guessing on who is using what version.
- Had in the past proposed a 'call home' in the code to register/track. That was not popular in the community. We don't have a way to contact people using the platform outside of the community. If there is an expectation of support, we also need to have an expectation of community. Could be phrased as an opt-in, that benefits Fedora for strategic decision making. The more you can give to the community the more you benefit.
- On the splash page of Fedora installation, there is a link to the registry of Fedora users, encouraging self-register. Is there more we can do to incentivise participation.
- Could we have service providers helping people install share this kind of information? We could look into strengthening this language.
- Can we bring this to the Communication and Community strategy groups
Action Items
- Draft letter about Strategy and Vision (Stefano), along with executive summary (David will get in touch with Aaron Choate who offered to draft the summary), to send out to the Fedora community.
- Voting on the Policy for long-term support and Supported JVM will happen over email soon.
- Raise the topic of how to get better data on who is installing/using what versions of Fedora with the Communication and Community strategy groups.