Attendees

1. Laurie Gemmill Arp 
2. Jon Dunn (first ~45 minutes only)
3. Jennifer Gilbert 
4. Arran Griffith 
5. Scott Prater
6. Robin Lindley Ruggaber 
7. Oliver Schöner 
8. Timothy Shearer 
9. Terry Reese 
10. Kate Dohe 
11. Rosalyn Metz  
12. Heather Greer Klein 
13. Maria Esteva
14. Alexander Berg-Weiß 
15. James Alexander 
16.  Nicole Scalessa 
17. Dan Field 

() Indicates Note Taker

Agenda

Notes:

1. Budget proposal (Arran)

$24,334 over budget for next FY:
 * Dan Field going to 80% to Fedora on Oct 1, 2024
 * 4 members dropped (-$30,000) (worst case scenario)
 * new members: +$5000
 * membership level increases: +2500
 * Travel

Goal: increase technical resources for Fedora (increased adoption, tech debt to pay off)
Tech investment: updating outdated dependencies
Funding for Mike Ritter will cease

Q: $25K of rainy day funds to spend this year?  
A: Yes. May not need to spend that much, if member income turn out better.  Keep in mind that Dan going full time will be expense beyond next year.  But good return on investment.
*Budget approved.*

2. Tech update (Dan Field)

Fedora 7: upgrade libraries (Spring, Java, Apache, Postgres, ActiveMQ, Jetty)
No API changes -- build dependencies changes
Q: Major version change necessary? Strong signal to community.
A: Build dependency, integrations a major, possibly breaking change.
Comments: Major version change a pressure point; may create a perception change that Fedora is not stable.  Fedora 6 intended to be stable, long-term, to calm the community after churn around Fedora 4 and 5. Fedora 6 was a complete rewrite, designed to be more like 3. Fedora 3, 4 and 6 fundamentally different products.  Will 7 be another fundamental change? Perception in community that 7 will be another major breaking change. Fedora 6 is a good use story, with great branding. Fedora community is not a fast-moving community, change is perceived as
cumbersome.  Security changes is important, but want it to be perceived as not a source of anxiety.
So:  do we want to reserve major version changes for big changes, or start making community comfortable with smooth major changes?
Are we ready yet?  Good place to get to, but maybe not there yet. 
We should make a roadmap of the future, make it public, so people can plan.
Perhaps take a long-term-support plan, with a common release pattern of time-bound support for a given version, while new versions are released.
We do need to deprecate support older libraries, too, which can be done by version-by-version.
We should think about our versioning plan, then, come up with a release plan and a communication plan.  We should use historic perceptions to determine what we want to do going forward, but not necessarily adhere to them slavishly.  We have the opportunity to change the narrative on what a major release looks like, what it means for our community.
Fedora version 7 has not been decided on definitively; next could be a minor release, but may be a year or two out.
Intention is that upgrade will be seamless and transparent as possible.

Progressive testing for performance: recording test results, realized that memory and CPU are not being stressed;  writes are expensive, as are ingesting many small files (problematic for some kinds of file systems)
Focused on high-performance computing environment, but has uncovered some generic problems
Goal: working on parallel ingests, to shift load back to CPU and memory
Thanks to TACC team and Maria Esteva for discussions around performance
Variety of storage systems, options much more varied than originally understood; improving performance is an onion, taking into account the entire stack, and costs with each solution (time, money, maintenance...)
Q: Is OCFL a bottleneck?
Comment:  Fedora needs to be performant and efficient, but doesn't need to scaled to high-volume real time requests
A: Current bottleneck is write operations; sheer writing of large number files is primary concern.
Comment:  This is a great use case, and time spent addressing it is well-spent. If we can offer users tips on tuning their architecture, that is a really big win.

Removal of one-click option.  Designed for testing, not for production.
Relies older version of Jetty; relies on older version of Java.  People now use docker.  Currently broken; nobody in community seems to miss it.