A Modest Proposal: A Technology Innovation Lifecycle Process for Fedora

Project Discussion
,
1

AI policy note:
The content here started as a Google Document, and I did ask Gemini to draft the inline tables which I reviewed. The rest of the text is lovely hand crafted, replete with grammar and spelling mistakes.

Introduction

This proposal outlines a structured process for introducing, developing, and potentially integrating experimental features, components, output, process or services within the Fedora Project. Some of you may have heard me refer to an idea I’m calling the “Fedora Sandbox.”
I’m starting this thread as part of starting the discussion around a process that starts with a sandbox for innovative technologies.. but really its a lifecycle process, that starts with a sandbox.

The goal of establishing a “Fedora Sandbox” is to provide a low-barrier, high-visibility environment for innovative ideas to be tested, refined, and validated by the contributor community without immediately impacting the stability or release process of the mature project outputs..

What is this really?

This is an idea to help the Fedora Project make a space for experiment concepts and build sustainable interest in innovative ideas, without committing to fully integrate them into the Fedora Project before they are assessed to be sustainable. This proposal had a genesis in the RHEL 11 planning meeting discussion in which I was able to sit in on as the Fedora Project Leader.

What technologies are in scope?

Technologies that need time to mature in any of 3 key aspects:

  • Technical Maturity: Does it work well enough to be fully integrated into the Fedora Project?
  • Community Interest: Do we think it’s sustainable based on contributor interest/commitment level?
  • Market Fit: Does this actually solve a problem for users?

What’s the key idea?

This process proposal focuses on a structured technology innovation lifecycle, with explicit gating criteria between lifecycle stages, and time-based explicit review points. The intent is to help foster the sustainability of innovative technologies by providing a pathway towards full integration into the Fedora Project with explicitly agreed-on exit criteria established when entering each lifecycle stage.

What’s the proposed lifecycle?

Gate: Entry Proposal
Stage: Sandbox
Gate: Sandbox Exit Review
Stage: Curated
Gate: Curated Exit Review
Stage: Integrated
Gate: Maintenance Review

Each gate represents a review point with success/fail criteria established at the previous gate. Technologies can be retired at every gate point.

The sandbox and curated stages are new concepts that I’ll talk about in detail in this thread. The integrated stage is what we currently expect from technologies that are available in the Fedora Project.

What do I want this initial discussion to focus on?

I want to focus the first round of discussion on the high-level structure of the proposal, the lifecycle stages and the general gating criteria. Does this make sense structurally to help the project better innovate and help cultivate sustainable ideas and/or weed out unsustainable ones while lowering overall risk to the Fedora project?

If there is reasonable consensus that there is value in a lifecycle process like this, we can then drill down into the details about the gates and the stages with more specificity and try to understand what structural changes and infrastructure we need to invest in in order for this to work. I expect what we will find is every time we use this process, we will discover some structural improvement that makes it easier to utilize the process. But we have to start somewhere. So let’s start with my straw proposal.

Objectives of the Technology Innovation Lifecycle Process for Fedora

  • Foster Innovation: Encourage contributors to bring forward new ideas, technologies, and features that may be too immature for direct inclusion in a standard Fedora release.
  • Isolate Risk: Provide controlled environments and outputs where experimental changes can be tested, broken, and fixed without affecting the main distribution branches or the experience of general Fedora users.
  • Gather Early Feedback: Facilitate early community and stakeholder engagement to gather feedback, identify potential issues, and guide the development of the experimental feature.
  • Establish a Path to Integration: Define clear criteria and a structured transition path for successful Sandbox projects to move toward becoming official Fedora features, services, or outputs.
  • Promote Transparency: Ensure all experimental work is visible and accessible to the broader Fedora community.

Implied Structural Project Changes

  • Possible trademark policy changes, including a possible subbrand for outputs that incorporate sandbox/curating technologies
  • Relaxing of project requirements that create quality safeguard for sandbox/curated
    • Legal requirements must be maintained through the technology lifecycle

Sandbox Entry

1. Proposal Submission

Any contributor or team wishing to submit technology into the sandbox must submit a formal proposal.

Expected Proposal Elements:

  • Project Name and Description: A brief, clear overview of the feature/component.
  • Goal/Objective: What problem does this project solve or what new capability does it introduce?
  • Scope and Deliverables: What specific code/packages will be developed or modified?
  • Exit Criteria: A clear, measurable definition of what success looks like for the project to graduate from the Sandbox (e.g., passing specific test suites, achieving a minimum number of active users, stability metrics).
  • Maintainer/Team: Identification of the individuals or group responsible for the project’s development and maintenance within the Sandbox.
  • Resource Needs: Initial assessment of necessary infrastructure (e.g., separate COPR repositories, dedicated testing environment, expected user-facing outputs).

2. Initial Review and Approval

The Fedora Engineering Steering Committee (FESCo) or a designated working group (e.g., the Sandbox Review Board, once established) will review the proposal.

Review Criteria:

  • Alignment with Fedora’s general mission and technical direction.
  • Feasibility and clarity of the proposed scope and sandbox exit criteria.
    • default exit criteria: must show sustainability along 2 of the 3 key aspects
      • technical maturity → does this work well enough to be fully integrated
      • market fit → does this solve a user problem
      • community engagement → is there enough community contribution
  • Explicit statement of allowed exit paths and conditions.
    • e.g. Under what conditions is this allowed to go back into the sandbox for further development versus retired?
  • Availability of a dedicated maintenance team.
  • Adequacy of risk isolation (ensuring the project truly poses minimal risk to the main distribution).
  • Time affirmed exit review date. The date on which an exit review is mandated to be performed.
Milestone Description Responsible Body Outcome
P-1: Submission Formal proposal submitted with all required elements. Proposing Team Proposal is drafted.
P-2: Initial Vetting Review against basic criteria (alignment, feasibility, team). FESCo/Review Board Approval to enter Sandbox or Request for Modification.
P-3: Sandbox Entry Project is granted a Sandbox status and assigned necessary resources (e.g., COPR access, mailing list). FESCo/Review Board Active development begins.

3. Development and Iteration (In the Sandbox)

Sandbox projects operate mostly autonomously within the Sandbox environment, leveraging tools like dedicated COPR repositories for package distribution to early adopters and testers if needed.

Key Requirements During Development:

  • Regular Reporting: Maintainers must provide brief, quarterly updates on progress toward the Exit Criteria.

  • Clear Labeling: All packages and features must be explicitly labeled as “Fedora Sandbox” components.

  • Community Engagement: Active participation in a dedicated communication channel (e.g., mailing list, Matrix room) to solicit feedback.

4. Exit Review and Graduation

When the project maintainers believe they have met the defined Exit Criteria, they submit a request for an Exit Review.

Exit Review Process:

  1. Documentation of Success: The team submits evidence demonstrating that the Exit Criteria have been met (e.g., test reports, user adoption statistics, stability metrics).
  2. Final FESCo Review: FESCo evaluates the evidence and assesses the project’s readiness for mainstream integration.

Potential Outcomes of the Exit Review:

Outcome Description Next Steps
Graduate/Integration Project successfully met criteria and is deemed stable, maintainable, and valuable. Integrate into Fedora proper (e.g., official package inclusion, FESCo Change Proposal for default inclusion).
Extend Sandbox Time Criteria partially met; more time needed for stabilization or wider testing. Project remains in the Sandbox with revised Exit Criteria and timeline.
Enter Curation Status Exit criteria met, but there is still an key aspect that is deficient Project enters curation status with revised Exit Criteria after gathering appropriate supplemental resource commitments to address deficient aspect
Retire/Decline Criteria not met, low adoption, stability issues persist, or project goals are no longer relevant. Project is archived; Sandbox resources are de-provisioned.

Curation Entry

A project enters the Curation lifecycle stage from the Sandbox upon a mandated Exit Review (4. Exit Review and Graduation) if the following condition is met:

  • The project has successfully met its defined technical and development Exit Criteria but there is a critical deficiency in one of the key sustainability aspects (e.g., Community Engagement, Technical Maturity or Market Fit), which prevents immediate integration into Fedora.

Requirements for Curation

Projects entering the Curation Status are explicitly granted a reprieve from retirement, for a set amount of time, contingent upon a clear plan to address the deficient sustainability aspect.

  • Commitment to Address Deficiency: The maintainer team must submit a supplementary plan detailing how the identified deficiency will be addressed (e.g., a plan for broader community outreach to increase engagement, or a market research plan to validate user problem-solving). This plan must include commitments from relevant stakeholders (e.g., Marketing/Outreach team members, additional developers, or potential external partners).
  • Revised Exit Criteria: New, measurable Exit Criteria must be set, focused specifically on overcoming the previously deficient sustainability aspect.
  • Curation Exit Review Date: A firm, date-affirmative review date must be set, typically within 12 months, after which the project must either successfully exit Curation or face retirement.

Success Criteria for Exiting Curation

Success is defined by the project demonstrating significant, measurable progress in the deficient area, proving sustainability along all three key aspects: Technical Maturity, Market Fit, and Community Engagement.

Implications of Curation on Project Policy

It is expected that necessary project policy adjustment discussions should happen as part of the curation process. Policy alignment problems should be identified on entering the curation stage, and commitments to address the policy alignment problems need to be made at that point, with the goal of having policy adjustment discussions be resolved by the curation exit review process. The intent is to do all necessary work during curation that can lead to a successful curation exit review.

Outcomes of the Curation Exit Review

The Curation Exit Review is mandatory on the pre-determined date and is conducted by FESCo/Review Board to assess progress against the revised Curation Exit Criteria.

Outcome Description Next Steps
Graduate/Integration Project successfully met Curation Exit Criteria, demonstrating sustainability across all key aspects. Integrate into Fedora proper (e.g., official package inclusion, FESCo Change Proposal).
Extend Curation Time Significant progress was made, but more time is genuinely needed to solidify the necessary commitments or adoption. Project remains in Curation with final revised Exit Criteria and a short, fixed timeline extension (maximum 6 months).
Retire/Decline Curation Exit Criteria were not met, or commitments to address the deficiency were not fulfilled. Project is archived; Sandbox and Curation resources are de-provisioned.

Integrated Stage

The technology has “graduated” and can be fully integrated into the Fedora Project. It’s anticipated that this will happen via a symbolic ChangeProposal process that FESCO is able to approve.

Maintenance Review

For “graduated” technologies that merit it due to the level of impact or complexity, the technology proposing team, or FESCO, or Council can authorize an additional maintenance lifecycle gate that triggers a date-affirmative review similar to the curation stage exit review. The maintenance review is meant to assess the continued sustainability of the integrated technology. This review is meant to identify technologies that are struggling and thus present a risk to the project. Projects that fail the maintenance review are expected to be sent back to the curation stage process again, with resource commitments identified to help address the sustainability deficiencies. Moving back to curation also acts as a signal that this technology may be on a path towards retirement if sustainability deficiencies are not able to be addressed.

Each successful maintenance review should be treated as re-entering the integratied stage again. Whether a maintenance review is required should be explicitly decided on each time a technology enters the integrated stage. It is expected that most technologies that move through the lifecycle process will require at least one maintenance review. The important part is to be explicit about the requirement each time a successful curation exit or maintenance review happens.

7 Likes
2

Hey Jef,

I really like the idea and thank you for bringing this forward. After reading it (and I probably will need to read it a few more times) here are some thoughts:

  • the “increased bureaucracy”: for FESCO could become a bottle neck and then people spending a lot of time phrasing their proposal
  • what will be done if a project is unstable / insecure? Will there be check mechanisms (which depending on the tech might be tricky) - bear with me here, there might be an easy answer to it but I am a tech noob
  • The “Curated” stage is designed as a reprieve for projects that are technically sound but lack community interest or “market fit.” –> we may end up with projects being on “life support” only.
  • Market fit / does it solve a problem for users –> this seems to me very subjective, espec in the open source context. How could we ensure that possible unpopular topics have all an equal chance, espec if we would look at ‘new’/young contributors
  • The addition of a “Maintenance Review” means that even after a technology is integrated, it is subject to periodic audits and potential “demotion” back to the Curation stage. And who will ensure the infrastructure is maintained without adding to tech debt / responsibilities/ burn out
  • what are success criteria for this project and when would it be stopped? Where do we hit break even?

I have no solution to these questions nor an idea - I am sorry for that - but I hope for some ideas from everyone in the community…. or maybe you have some answers. Or maybe we do not need answers to all of them.

In general I think it is worth to experiment with this concept and I really appreciate that you took the time to think about this and bringing it forward. If anything is confusing please let me know. I also apologize for any potential typos.

Cheers,
Julia

4 Likes
3

This proposal could allow more/bigger/better changes in Fedora, more innovation, etc. If it works like this, it’s worth to do it.

I think the general structure looks good. The important part is that there’s a documented process with established steps for summaries and reviews. How the steps are called and the details of the schedule are secondary. (The process is a bit heavy, but not excessively so.)

One deficiency or weak point of this proposal is that it’d work nicely for things which are self-contained, but not for changes that require integration across the board. So for example, it should work nicely for a new deliverable, or a language ecosystem, and other “additive” things. But it might not be great fit for things that require changes in infrastructure used for other tasks, formats, packager behaviour, etc. If there are non-trivial changes in other parts of the ecosystem, we cannot easily say “let’s now undo”, or even “let’s put this back in sandbox”. Any such changes must have agreement and a clear contingency plan before we real work starts. I don’t think we should not try this, but I expect that it won’t quite solve the problems we have with big structural changes.

3 Likes
4

Overall I like the idea and I think it’s inline with what we’ve been trying to do from a technological perspective with Communitshift. This proposal is focused on the process with it’s criteria and gates which makes sense. I’m curious if you see this as atop our current offering with additional community marketing or if this would be a totally greenfield effort.

5

Hmm, as of right now I don’t really understand this as increased bureaucracy. I think of this as staging things out a bit and being much more explicit. Currently a technology has to get through FESCO review somehow. Right now having had a lot of quiet conversations, my sense is we probably have a bias against experimenting inside the bounds of the project.

With regard to FESCO, the process makes a space for FESCO to delegate this out.. but as governance is currently constructed FESCO has technical oversight authority and this proposal needs to be respectful of that. What I hope this does in practice is make fully integrating things far less contentious and actually drops the active work FESCO has to do. Something run through the sandbox and curated stages should ideally just be a ceremonial changeproposal process. The first project through probably wont be, but as we iterate on this.. that’s what I hope happens.

The sandbox is explicitly stood up so things can be unstable and broken…
Gather round technology enthusiasts, come look at the shiny broken sharp things that you can help polish up using your own blood and tears, into something great.

If Fedora as we know it( is in my mind at least) is the integrated stage in the process, then the integrated stage is leading edge, and sandbox explicitly is allowed to bleed. Since we currently do not have a legal requirement that mandates secure outputs or stable outputs, these are quality concerns that must be addressed at some point because they are expected from fully integrated technologies. But do we need them addressed in the first gate? I don’t think so. They should be identified as concerns and addressed before integration.

Curated is where we figure out how to address deficiencies with some focus. If quality is a concern, what I hope we can figure out how to do is offer the QA team to teach the group of people pushing the technology on how to write and integrate testing. What I do not want to do is overwhelm the existing QA team by asking them to taking on more work. We need to move to self-service of quality…which may mean using our experts to mentor people during the curated phase and expand the sphere of knowledge about how to use the QA testing infra we have to self-service in a sustainable manner.

I would place security as a technical maturity issue. If on exit review from the sandbox the security isn’t sufficient its a technical maturity deficiency that needs to be addressed in curation assuming other aspects are in good shape. Again this is a straw proposal, if security is a big enough issue to have it as a 4th aspect on its own… sure. maybe. The point is entry in to curation needs to show the technology is mostly there towards being integratable. And we need to be able to identify supplemental resources in curation that can help mentor the people championing a technology over the line.

How do we prevent burn out now? How do we assess if infrastructure is sustainable now? You’re talking about systemic problems that is probably already happening. This process should make things much much more explicit about what the expected level of volunteer best effort is sustainable and which new services are too critical to be treated in a best effort fashion.

We have to start being honest with ourselves about when things fall below sustainable levels, and we have to be explicit about the options we’ve agreed to about when that happens. If we are already in a resource deficit for things we maintain and consider critical, that’s a problem on its own. But what I’m very sure of is we can’t just keep adding more and more things without setting some expectations about sustainability. We prevent burn out by being explicit about what we think is sustainable and what is not. We give permission to our future selves stop doing things when they aren’t sustainable any longer by setting some explicit criteria that latch on a review process some time in the future.

That’s going to require discussion, which I want to hold off until the structure here has sufficient buy in. I expect criteria will be an evolving framework and will be context specific to each project. There is some measure of blast radius analysis. The bigger the blast radius, the higher the sustainability threshold is right?

2 Likes
6

Hmm..

I could appreciate enhancements along these lines.

We need to find a way to fashion changes that can be rolled back as much as possible. If they can’t be we have to designate them as critical and have an explicit lifecycle pathway that speaks to the sunstainability of critical things. But everything can be shutdown, its just that somethings are way more painful and we need to be explict about that.

I would address your concern this way… there can only be a set number of things that are critical inside the project. We must be explicit about what those are and we must be explicit about what capacity we have to maintain those critical things. If our capacity shrinks we must be honest with ourselves cocerning how we take the hit and add capacity to maintain the critical things. At this point, if we are adding critical things with the expectation that those critical things are going to be managed via best effort.. we are significantly adding risk to the project. We should endeavor to stop doing that. And the way we do that is to be as explicit as possible that something is critical and needs a higher level of committment before we integrate it.

2 Likes
7

An interesting proposal! Thanks Jef.

I also wonder about how we handle when something that wants to use this
process interacts with existing stable part of the project, but I
suppose we could take those sorts of things on a case by case basis.
and/or try and come up with ways to avoid such entanglements if we can.

How would these sandboxed projects infrastructure be handled?
I don’t think we want to just tell them to build things on their own
dime, but also don’t want to provide them fully staffed and resourced
infrastructure (unless requirements are small). I could see a middle
ground, perhaps leveraging communishift + aws resources (thanks amazon!)
and having the sandboxed project manage things themselves?

I can see this adding load/process to fesco, but perhaps it would be
ok, depending on how many projects were going at once. Would handling
the process here be something the Fedora Operations Architect would take
on? The process of requesting checks/keeping docs flowing/etc I could
see being a lot of work and get off track if someone wasn’t keeping it
flowing along.

Finally, do you know/have some things that might be good candidates for
this sort of process? I would think that if we have some things saying
they would use this process would be very helpful to trying to adjust
the process along with avoiding ‘if you build it they will come’
syndrome. Also, examples might help people see where this process would
be useful/better than not having it at all.

kevin

3 Likes
8

Sorry for stupid question, but what is this good for? Do you have some example feature this is aiming at?

9

The proposal itself sounds like something that would be worth doing, if only to allow enabling “experimental” technologies to “prove” themselves before being included in Fedora “proper”. However, I see some potential issues (or at least questions) about how the Sandbox mechanism would actually work:

For example, where would sandboxed experiments that affect alternative (or additional) versions of packages / images / deliverables get developed (where would the sources live?) and built? CentOS Stream has CBS for this, where CentOS SIGs can do something similar, but Fedora does not (yet?) have an equivalent “second koji”. Who would provide and maintain this additional infrastructure?

On the other hand, some Sandbox projects might require changing some Packaging Guidelines and / or FESCo policies. One example that I could imagine would be a Sandbox project to provide alternative Kernel packages that enable some experimental features or include non-upstream patches, or even kmod packages to ship kernel modules that are not enabled in the “stock” Fedora kernel. Both would (currently) violate the Packaging Guidelines, which only allow for one kernel package and no kmods external to the kernel. Do you expect to update docs / policies and guidelines to account for Sandbox projects like when needed?

1 Like
10

The one part I didn’t see in the OP proposal is how do we stop putting project resources on things when they either don’t pass into the next stage, or are no longer fit in any way without a rewrite.

I bring this up because we have had many proposals over the years of how things should get into Fedora as a service or deliverable.. and so we have ended up at times like a vaudeville show where they keep putting out spinning plates until the people trying to keep them going fall over ‘dead’. [I sometimes feel like it is our view of the ‘Aristocrats’ joke but the end line yelled out is ‘Infrastructure!’]

Thus could you add in your thoughts on how projects, deliverables and services are no longer ‘sponsored’ by Fedora. Someone or some party has to be empowered to say ‘we can no longer do this’ and those decisions need to be supported versus ‘well can you keep it going for one more cycle? its only a server or two.’ because that always comes with ‘oh and how is that other project we told you to have by release date’

2 Likes
11

Thanks for putting this proposal together! I like the structured approach to isolating risk while fostering innovation.

To help ground this, here’s a practical example of a potential sandbox project: fedora-bootc-nvidia, a prototype of Fedora Atomic using the NVIDIA open-source drivers. Under this proposed lifecycle, we could experiment with a second kernel signed with Secure Boot keys. During the Sandbox stage, this kernel could be built in COPR. Upon graduating, it would transition to being built directly in Koji and the main Fedora repos.

This example also highlights what I think should be a core goal of the sandbox: onboarding new contributors. It would likely be much less intimidating for someone to get involved in packaging an experimental sandbox kernel. As they learn the ropes in a low-risk environment, they build the skills needed to eventually share the load of maintaining the primary Fedora kernel.

However, we still need to clarify the incentives. Why should a project or enthusiast participate? In ecosystems like the CNCF, projects invest heavy initial effort into governance because they directly benefit from the foundation’s recognition, gaining traction, contributors, and users. We need to ensure the Fedora Sandbox offers a compelling value proposition to offset the process overhead.

I worry that the friction of the initial submission process might actually discourage great ideas, and potential new contributors, before they even get off the ground.

Looking forward to seeing how this evolves!

Assisted-by: Gemini (3.1 Pro)

1 Like
12

Sandbox entry should spell out infra asks. And infra can say no based on capacity. I’m hoping infra can develop a “no brainer” menu for Sandox that includes AWS resources the sandbox technology group can self service.

Part of this has to be making infrastructure requirements explicit so the group bringing the technology forward can find/develop the right infrastructure sustainability coverage with them.

I’m also hoping that if we do this correctly, the infra team is able to mentor a group through the curation stage if there are special infrastructure needs to get to fully integrated. Not do the work, but to mentor in people who have been self servicing in the sandbox so they can fully integrate.

First let me also state, the sandbox itself will have to have capacity limits.

I placed fesco in specifically to ensure it was clear that ultimately the gate between curated and integrated needs to have fesco sign off. What I want is for that decision to be as ceremonial as possible… but that means fesco technical or policy concerns at the sandbox exit need to be surfaced then so the curation stage can be used to address those concerns. So we need to make sure there is some engagement point where concerns can be surfaced so they can be addressed in curation.

Chicken and egg problem. The best question that could be asked right now is what would have gone better in the past if this were a process available? The next best question is, what was never attempted to be integrated into Fedora that would have been attempted if this were available as a process? The third best question is what ideas are out there in people’s heads that are big enough to benefit from access to self-service time boxed sandbox starting point? I can beat the bushes a bit and try to encourage people to answer that third question. But I’d be asking them to be a little vulnerable with concepts for ideas they haven’t been public with, and I don’t want this to be a pile on on ideas that aren’t ready to be submitted.

13

That is a reasonable concern. My hope is that the initial submission process is there not to discourage but to unlock possible innovation that is too risky otherwise.

If we can collectively decide what an accepted sandbox project gets in terms of standard resources, and we can get consensus on what the standard exit gate conditions look like that would probably go a long way to addressing your concern. Anything that can make use of a standard set of resources and can commit to meeting that standard set of exit gate conditions, should have easy entry. It’s the ideas that need more than what we can commit to explicitly resourcing for a self-service sandbox space that would require negotiation that will have some amount of friction entering. But those things would have more friction entering via a standard ChangeProposal process as well.

My hope is there is consensus on the structure of this proposal and we can then move on to defining the details of what a standard sandbox experience gets in terms of self-servicable infrastructure and what is expected from it in terms of exit criteria to enter curation status.

Or asked another way, what is the value proposition to being fully integrated into the Fedora Project?

This proposal doesn’t directly speak to that question… this proposal assumes that sustainable full integration into the Fedora Project is a valuable end state to those who are making the sandbox proposal. And I hope this provides a better way forward than the pathways that currently exist when the ideas are big enough to need experimentation, or are reaching out to a new pocket universe of potential contributors not well served by the existing outputs. I’m not expecting frictionless, but hopefully this provides a less riskier pathway that makes it possible to try to do things within the framework of lifecycle stages.

And instead of answering the question, I’ll ask a couple of related questions.

First, for people who see the value proposition of a technology being fully integrated into the Fedora Project, do you think the framework here gives you a better pathway to implement more innovative ideas than you have right now? This question should be answered in this thread as discussion may materially impact a formal proposal draft.

Second, for the other group, the people who don’t see the value proposition of fully integrating with Fedora, what would sway you that this is a valuable state for an open source technology to achieve? If there is something that the project isn’t doing, but legally could, that made it more desirable as an integration target… what is it? We should probably take this question to a separate thread as it probably will not materially impact this proposal, but is more speculative in nature and may impact future policy adjustments.

14

Hmm,
Does this help? For the purpose of the straw proposal let’s assume that a standard exit condition out of the sandbox stage will be “decommissioned” and we are explicit that the infrastructure for that sandbox will be disabled no earlier than 6 months after the decommissioned exit path is decided on as part of exit review.

One of the points of the structure is that the exit conditions for each stage are well known prior to entering the stage. The intent is to make the decommissioning/sunsetting/retirement conditions explicit at the start of each lifecycle stage so we avoid the goal post moving at the close of the stage. This is also why there is a recurring maintenance review after integration, to explicitly recommit or renegotiate a set of requirements for a reasonable period of time.

What I hope we can do is once there is consensus that this structure is reasonable, is that we can concoct a standard set of sandbox exit criteria and pathways… one of which will be something like the decommissioned pathway I described above. A sandbox project that explicitly agrees to the standard set of exit criteria and pathways would need very light entry review.. but they would also explicitly know at the start of the process how and when their infrastructure gets turned off…and as a project we’ve collectively agreed to hold ourselves to that explicit commitment.

15

Hmm would a CBS-like thing be a good first project to run through this process?

I fully expect that projects in the lifecycle process will break documented policy in both the sandbox and curation stages. If this process is adopted there may have to be significant changes to clarify that the fully integrated project outputs will be expected to meet policy and guidance. We may need to have a trademark subbrand for outputs that integrate sandbox and curated stage technologies separate from the main brand to help with this clarification.

Non legally binding policy applies in my head like this:
MUST-> integrated
SHOULD → curated
MAY-> sandbox

For policy violations that survive from sandbox to curated, we have to have a reasonable path forward towards resolution in time for integration, and that should be discussed as part of sandbox exit review, so that the correct stakeholders are talking about corrective actions for policy alignment during the curation stage.

1 Like
16

One thing that could be instructive is - given the worry about how much infrastructure all the sandboxed projects might consume - how many of the “next generation” infra projects would be sandboxed as well under this proposal?

I feel like all the back and forth around, say, Konflux, would probably have gone over much better with a framework like this in place. I’m also slightly concerned that the administrative barrier might be a bit high, but we can tweak the details later.

17

I would hope that the benefits of this lifecycle structure would make it possible for all new infra projects moving forward could commit to this lifecycle structure. I’ll go even further and say once we gain experience with the full process, we could even put mature infra bits into the process so they gain a maintenance review gate and benefit from explicit sustainability expectations with potential remediation via curation.

I think the Konflux experience is something I think would be reasonable to think through, yes.

My view is, how Konflux has been introduced is effectively a very loosely defined sandbox, with a false start or two. Its on a path towards integration now because its started to get some traction from contributors interested in using the technology. But there’s is less clarlity on the expectations on what a sustainable konflux implementation for Fedora looks like, and as a result there is more anxiety about it then there really needs to be. A lifecycle process with clear stage exit expectations and review points may have helped get clarity around what is expected from a sustainable Konflux integration.

Konflux is also one of those pieces of technology that may eventually be integrated deeply enough to be considered critical path infrastructure. So its also interesting to think about it from that pov. This structure of this proposal very deliberately doesn’t address things that are known critical path items and is expected that everything that goes through the lifecycle process can be retired if its found to be unsustainable and can’t be remediated with curation stage commitments to bring the effort back into a sustainable state.

If you’ll pardon me from going on a tangent just a little bit…
We have to be very careful about designating things critical path, and be very honest with ourselves about how much of the project output requires critical path commitments, who is only the hook for those commitments, what the true critical infra commitment capacity is, and how much of the project should be self-servicable.

I’m happy to breakout a discussion about critical path capacity as a new related topic if there are thoughts on that that need to be explored. I think a much more robust discussion about explicit critical path commitments and capacity will be impactful and in scope once the forge implementations are fully stood up and we can experiment with self-servicable workflows that take advantage of forge action runners.

18

I wrote up some thoughts on this proposal, using Podman’s early days as a case study. I was there for pretty much the whole journey, from the rejected Docker PR that spawned Skopeo in 2016, through the constant pressure to justify resources, to eventually becoming the default in RHEL 8.

The short version: a formal Sandbox with transparent metrics and clear graduation gates would have made that path less painful. Real validation came from Ubuntu and Debian picking up Podman independently, not from Fedora inclusion, which was dismissed as a corporate rubber stamp. A Sandbox process could change that perception for future projects.

Blog post here: Why the Fedora Sandbox Would Have Helped Podman Survive Its Early Days Crunchtools

Curious what people think, especially anyone who’s shepherded a new project through the Fedora ecosystem. I think this proposal could attract that new kind of contributor.

2 Likes
19

BTW: LWN article on this today.[1]

  1. Are you a Fedora contributor without a LWN subscription? We have a group subscription. It’s currently full, but I see that some people haven’t logged in into over a year, and I’ll prune them off in favor of someone who would actively use it. ↩︎

20

Quick follow up.

I’m actively reaching out to existing project leads inside Red Hat to find concrete project examples that can be used to publicly refine this modest proposal into something actionable.

If there are community ideas floating around in people’s heads that want to be part of a public refinement, I’d also love to hear from you.

Proposal refinements I want to establish by playtesting with real project ideas that see benefits in this process include:

  1. Define what standard sandbox should /could provide.
  2. Define the standard gate criteria for entering/exiting the sandbox stage
  3. Better define the curation stage as evolution of council initiative process