Page Comparison

• Jenn Colt Discussed proposal document with tri-council co-chairs meeting.  They thought yes/no question was unnecessary, go right to timeline for Eureka official and Okapi end of support.  Although not setting a timeline is also a no.
  
  • Marc Johnson We should document if that's what we've done, i.e. that the decision has been made.  Understand the timeline framing, and why people think no-adoption is not viable.  But that makes timeline equally pointless to discuss, if chairs already have that sense from the community.  Chairs need to figure how we document that.
  • Jenn Colt We can attribute it to the FOLIO chairs.
  • Craig McNally Add that to this document.
  • Maccabee Levine Deciding 'yes' still doesn't answer the 'how' part, which is what the single RFC addresses.
    • Marc Johnson Disagree.  If we frame this doc as a decision, then the "what" and "how" of technical architecture, all of that stuff is a waste of time to discuss with RFC process and debates, in any of the councils.  The purpose of going through and RFC is to provide feedback to the folks making the proposal to make changes, then to decide whether to adopt.  If underlying assumption is that community is adopting this and the question is when, then there is no value in talking about the 'how' or what components.  Except as a learning / sharing knowledge exercise, good to do, but addressed through different mechanisms that EBSCO is already doing (i.e. documentation efforts and early adopter programs).  Maybe also room for feedback on potential changes in the future, but that's not a timely matter, can come later.
    • Jenn Colt One thing is that TC is providing a service to the other councils.  RFC question may be internal to the TC if the community says "yes and aiming for particular release."  So may be for us but not answered at tri-council level.
    • Marc Johnson Agree with Jenn.  Impact of tri-council decision can be discussed at each council.  But no value to discussing RFC etc. until after tri-council meeting.  Should remove any 'if' references from this doc, except the RFC providing info that's not available elsewhere.  So RFC not part of decision-making process, but to fill in gaps.
    • Jenn Colt did restructure doc to focus on the timeline aspect.
• Tod Olson Constraining the timeline makes sense.  Only two options I see are to target Sunflower or Trillium as when Eureka becomes the primary.
  • Jenn Colt In the doc: assumption is that EBSCO will shift in Sunflower.  In order for the community to transition as well, here are the requirements.  Folks have added detail.  Option 2 is that if the community can't shift in Sunflower, other high-level requirements need to be met.  Could be specific that the second option is Trillium.
  • Tod Olson Didn't mean to say frame as a choice of Sunflower or Trillium.  Personally think we should be bullish.  But if Sunflower can't make it, Trillium would have to be the hard deadline.
  • Jenn Colt We have no control over release management.  Sunflower will probably be postponed as Ramsons was, but we have no say.
  • Marc Johnson With 'if' off the table, does 'when' matter anymore?  Bugfest operated by EBSCO at their cost for community.  If the council makes no decision about when until Sunflower bugfest, my understanding is that would be a Eureka-based bugfest.  So the only testing then would be on Eureka.
  • Craig McNally That is correct.  Table on doc indicates this.  If community wants to do separate Okapi-based testing, that's up to community.
  • Jenn Colt The 'when' decision matters because it's an issue of focusing resources.  Keeping community together if major developer moves to a new platform and no one else can go with them.
  • Marc Johnson EBSCO process is happening from Sunflower irrespective of community action.  Eureka already in production (on previous flower release).  If we're reframing, it's not Sunflower vs. Trillium, it's we're going in Sunflower, what do we need to do to get there or to catch up as quickly as possible if not.  If community says not Sunflower, it doesn't change bugfest, we don't have capacity to do that separately.  So realistically we might as well take the 'when' off the table as well.  Not a decision-making process, but a planning process, it's happening in Sunflower, how fast can we catch up all relevant parts of the community to get to that place ASAP.  How long after sunflower to get hosted reference environments swapped over, all the other things.  Disconnect from the releases, except the small things like platform definitions.  Effectively offering minimal dual support in Sunflower unless we can catch up fast enough, and that's it, after that it's Eureka-only.
  • Jenn Colt That makes sense to me.  This is recommendation for doing the best we can in Sunflower.  Good to still acknowledge that Option 2 would be a lot of work to maintain an Okapi version somewhere, and that's why it's not reasonable.  Can also simplify the timeline table, remove some of the community rows.
  • Marc Johnson We don't have to say it's a recommendation.  If the actual decisions have already been made, then this becomes a report, of the things that have to happen.  And the question becomes can we get there in time for Sunflower.
• Jason Root Community meeting next week to on-board devops to early adopters program.  Will work with German library consortia to get something running.  Want to keep reference environments, get those retooled.  Vagrant boxes still useful to many in the community for development support, Eureka has tiering to levels of the platform, that could make the Vagrant boxes easier to run on machines.  Eureka environments right now are being handled by Kitfox; the reference environments and Vagrants by FOLIO devops, by Index Data right now.  Early adopters program will involved Index Data devops, community devops, German libraries devops.
  • Marc Johnson So there is work for the community devops team to do with the hosted reference environments.  Enough for meeting to just say that community devops has work to do on this.  If someone has already put the effort in that satisfies the same need as snapshot env, what's the need for community devops to do that.  Since that work comes from community council funds.
  • Jenn Colt There are ongoing discussions for community responsibility for community infrastructure.  For us, wrote with assumption that ID has been doing devops and will continue, so they need to be ready to take over doing Eureka devops.
  • Craig McNally Hosted reference environments are slightly different, just running the tip of master and rebuilt regularly.  Wayne or Jason noted that the current tech stack for hosted reference environments is being replaced with Kubernetes, which aligns closer with what kitfox is using, so opportunities to reuse helm charts etc.
  • Jason Root Yes that is on the table, decisions not made yet.
  • Craig McNally Devops also hosts release-specific environments.
  • Jason Root  Yes.  Ramsons one not there yet.
• Marc Johnson Nothing else for the communities to do on this – little other governance.  Just the various devops operations.
• Maccabee Levine We should actually make the decision official.  We've been talking in TC about voting minimum numbers of people, and here we have effectively made a decision with two TC members (the co-chairs).  60 seconds of lazy consensus at the start of the tri-council meeting will make it official.
  • Jenn Colt Yes, to vote on this as TC after tri-council.
  • Marc Johnson Why would we do that, beyond upholding governance policies.  If we ask the councils to vote on this, our community never says 'no' on things, but if we ask the question we leave open the door to some folks saying no.  If that happens, we need to have an answer to what that means.
  • Jenn Colt Voting rqeuires people to be informed, lazy consensus easier.
  • Maccabee Levine Majority of all councils will say yes, and by lazy consensus.
  • Marc Johnson So first order of business is to do this by lazy consensus, and if no one objects, then that's the formal process.  Nothing in the agenda if anyone does object.  Rest of the meeting is the plan to get there.
  • Tod Olson Agree.  Once concern is about framing the initial statement so it's not 20 minutes of discussion.  Something like "we the three councils are resolved that FOLIO will be moving to the Eureka architecture.  This meeting is about the timeline."
  • Marc Johnson Specific language up to chairs.  They made the pre-emptive decision.  So wrangling how to frame it in a way that doesn't encourage active voting, but acknowledges that it's happened, is a challenge for the chairs.
  • Jenn Colt agrees.
  • Craig McNally Regardless what's in the report, someone will raise this.  How do we make it more productive.  Discussions at WOLFcon etc. have pointed to community embracing this.  If we frame it as an assmption it's the best we can do.
  • Maccabee Levine Just asking us to make it explicit, since we've been discussing how to make it official for a long time.  If it comes up organically it can be a long meeting again.  Get it over quick at the start.
  • Jenn Colt If the meeting doesn't go as we want to, there will be options.
• Craig McNally Tri-council audience will be diverse, some technical and some not.  Tricky to know what level of detail the doc should be.  Can't make assumptions about level of understanding, should use layman's terms.

Slack conversations:

• expectations around Eureka modules and the TCR process... Is the expectation that we should submit all of these for inclusion into Sunflower?  Is it too soon, given where we stand with the RFC process?  There's a lot here, so I think we'd want to get started sooner than later so we don't wind up with a huge backlog of these things closer to the deadline. https://folio-project.slack.com/archives/C02HP10PPGB/p1730467357615359
• I request that we put the 0010-eureka RFC into the next status stage on Monday. Implementers need a decision now whether the community adopts Eureka for Sunflower or not so that they can plan their work. https://folio-project.slack.com/archives/C02HP10PPGB/p1731076265224589

RFC in preparation:

• 0010-eureka

Relevant dates:

• Sunflower OST acceptance: Sept 27, 2024
• Sunflower scope deadline: Sept 27, 2024
• January tri-council meeting: Jan 13, 2025
• Sunflower API freeze? Jan 24 2025
• Sunflower module acceptance deadline: Jan 24, 2025
• FOLIO support period is the next release (currently in development) and the two latest GA (General availability) releases: PC Supports long-term release and regular release recommendations
• RFC public review timebox: 1 month

1. capacity... maintaining the hosted reference envs is not zero effort.  Kitfox may or may not have capacity to take this responsibility on long term, especially when considering #3 below.
2. cost... I believe the rancher envs are paid for by EBSCO, and the hosted reference envs are not
3. scope... As mentioned earlier, it's not only snapshot envs, but also the "release" envs