Call for help: Future of the Fedora i3 Spin in Fedora Linux 45

[Justin Wheeler]

Hello i3wm SIG & Fedora community,

I'm reaching out to the SIG about the future of the Fedora i3 Spin as
we work through the Fedora Linux 45 release cycle.

As some of you know, I was involved with the i3 SIG as a maintainer in its
earlier days, and I care a lot about the work this community has built
together. But I want to be honest about where things stand: active
maintenance of the Spin has been light in recent release cycles. We need to
determine if there are people ready to carry this forward, or if it's time
to make a graceful exit.

*## What needs to happen*

The Fedora i3 Spin needs active maintainers to keep shipping.
That maintenance work includes:

- *fedora-comps*: Keeping the i3 package group up to date with the right
   set of default and optional packages for each release.
   - *Bug reports & feature requests*: Triaging and responding to
   issues from the community.
   - *Package Integration*: Improving the integration between i3wm and
   Fedora Linux base packages in the official RPM repositories.
   - *Documentation*: The i3 SIG docs site on Pagure must be migrated or
   archived before the Pagure.io shutdown deadline of 31 July 2026.

*## What's possible*

This doesn't have to be the end of the road. There are exciting directions
we could take:

- *Fedora i3 Atomic Desktop*: The Sway SIG has an interesting
   model here. They ship both a traditional RPM-based Spin and a Fedora
   Atomic Desktop variant. There's no reason we couldn't do the same for i3,
   and it could renew interest in the i3 Spin.
   - *Sway as a sister project*: i3 and Sway share a lot of DNA.
   Closer collaboration with the Sway SIG could benefit both
   communities, especially around shared documentation and onboarding.
   - *Fresh energy*: Sometimes all a project needs is one or two
   people with enthusiasm and a bit of time. If that's you, we want to
   hear from you.

*## The timeline*

We need a clear picture by the *end of July 2026*. That gives us enough
time before the Fedora 45 release cycle ramps up to do one of the following:

1. Confirm we have enough maintainers to keep shipping the Spin, or
   2. Make a responsible decision to retire it, providing users with proper
   notice.

If we don't hear from enough folks willing to step up, I'll work with Aoife
Moloney, the Fedora Operations Architect, to begin retiring the Fedora i3
Spin for F45. I'd rather see new folks rally and keep it going, but I'd
also rather make a clean, honest decision than let the Spin ship without
anyone intently looking after it.

*## How to get involved*

If you're interested in helping maintain the Fedora i3 Spin, please reply
to this thread. You can also find us at:

- *Mailing list*: [e-mail] (*you are here!*)
   - *Matrix*: #i3:fedoraproject.org
   https://matrix.to/#/#i3:fedoraproject.org
   - *Fedora Discussion*: *#f45
   https://discussion.fedoraproject.org/tags/c/project/7/f45/1452* tag

Thanks for reading, and thanks to everyone who has contributed to
the Fedora i3 Spin over the years.

[Michael J Gruber]

Justin Wheeler venit, vidit, dixit 2026-06-30 01:30:18:
> Hello i3wm SIG & Fedora community,
>
> I'm reaching out to the SIG about the future of the Fedora i3 Spin as
> we work through the Fedora Linux 45 release cycle.
>
> As some of you know, I was involved with the i3 SIG as a maintainer in its
> earlier days, and I care a lot about the work this community has built
> together. But I want to be honest about where things stand: active
> maintenance of the Spin has been light in recent release cycles. We need to
> determine if there are people ready to carry this forward, or if it's time
> to make a graceful exit.
>
> *## What needs to happen*
>
> The Fedora i3 Spin needs active maintainers to keep shipping.

Thanks for taking care of the i3 spin so far.

I'm a former i3 user, current sway user, and I've never used a spin
other than Workstation. This is no criticism of any of the spins, just a
point of input that not every "niche DE" user is necessarily a spin
user. OTOH, there's quite some value in maintaining the DE packages and,
in particular, base config, even if there is no such spin. I know this
is different for atomic variants, but I'm wondering whether i3/sway
folks are really those who'd use a pre-baked atomic image, or rather a
base for their own (bootc?) images.

Speaking of the future: How much effort do we (does someone) want to put
into a DE which requires an X11 stack?

Michael

[CS Sushi Man]

> Speaking of the future: How much effort do we (does someone) want to put
> into a DE which requires an X11 stack?

It is far easier for a DE developer to maintain an X11 DE, since
they would only have to be concerned with having certain pixmaps
and rectangles drawn to the screen (like a titlebar), and some
input handling (like pressing the close button on a window).
Wayland on the other hand, requires a DE developer to maintain
their own compositor, which may also include dealing with GPU
memory management, handling rendering calls, handling input devices
directly, and things of that nature. The "DE" would now have to
store window locations, handle BLIT operations, handle the mouse,
handle display planes, framebuffers, and everything related. Pretty
much, the DE would now have to handle all the things previously
handled by the X server.

It is *far* easier to maintain an X11 DE, than it is to maintain
a Wayland DE/compositor. The DE maintainer, with X11, is only
concerned with how the user may interact with his machine, and to
forward those interactions to the X11 server accordingly. The DE
does not have to store window locations, mouse locations, or
anything of the like, since the DE can simply query them from the
server. The DE does not have to manage GPU memory, since X11 does
this for you via pixmaps. X11 will also handle BLIT operations, and
rectangle copies/draws.

With the Wayland protocol, the DE maintainer would be required to
make his own compositor, since the Wayland protocol does not allow
for these queries whatsoever. This does make the protocol itself
simpler, but it comes at the cost of combining a significant number
of responsibilities into one program, which were previously handled
separately.

Sent with Proton Mail secure email.

On Tuesday, June 30th, 2026 at 06:46, Michael J Gruber  wrote:
> Justin Wheeler venit, vidit, dixit 2026-06-30 01:30:18:
> > Hello i3wm SIG & Fedora community,
> >
> > I'm reaching out to the SIG about the future of the Fedora i3 Spin as
> > we work through the Fedora Linux 45 release cycle.
> >
> > As some of you know, I was involved with the i3 SIG as a maintainer in its
> > earlier days, and I care a lot about the work this community has built
> > together. But I want to be honest about where things stand: active
> > maintenance of the Spin has been light in recent release cycles. We need to
> > determine if there are people ready to carry this forward, or if it's time
> > to make a graceful exit.
> >
> > *## What needs to happen*
> >
> > The Fedora i3 Spin needs active maintainers to keep shipping.
>
> Thanks for taking care of the i3 spin so far.
>
> I'm a former i3 user, current sway user, and I've never used a spin
> other than Workstation. This is no criticism of any of the spins, just a
> point of input that not every "niche DE" user is necessarily a spin
> user. OTOH, there's quite some value in maintaining the DE packages and,
> in particular, base config, even if there is no such spin. I know this
> is different for atomic variants, but I'm wondering whether i3/sway
> folks are really those who'd use a pre-baked atomic image, or rather a
> base for their own (bootc?) images.
>
> Speaking of the future: How much effort do we (does someone) want to put
> into a DE which requires an X11 stack?
> Michael
>
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

[Neal Gompa]

On Tue, Jun 30, 2026 at 1:14 PM CS Sushi Man via devel
 wrote:
> > Speaking of the future: How much effort do we (does someone) want to put
> > into a DE which requires an X11 stack?
>
> It is far easier for a DE developer to maintain an X11 DE, since
> they would only have to be concerned with having certain pixmaps
> and rectangles drawn to the screen (like a titlebar), and some
> input handling (like pressing the close button on a window).
> Wayland on the other hand, requires a DE developer to maintain
> their own compositor, which may also include dealing with GPU
> memory management, handling rendering calls, handling input devices
> directly, and things of that nature. The "DE" would now have to
> store window locations, handle BLIT operations, handle the mouse,
> handle display planes, framebuffers, and everything related. Pretty
> much, the DE would now have to handle all the things previously
> handled by the X server.
>
> It is *far* easier to maintain an X11 DE, than it is to maintain
> a Wayland DE/compositor. The DE maintainer, with X11, is only
> concerned with how the user may interact with his machine, and to
> forward those interactions to the X11 server accordingly. The DE
> does not have to store window locations, mouse locations, or
> anything of the like, since the DE can simply query them from the
> server. The DE does not have to manage GPU memory, since X11 does
> this for you via pixmaps. X11 will also handle BLIT operations, and
> rectangle copies/draws.
>
> With the Wayland protocol, the DE maintainer would be required to
> make his own compositor, since the Wayland protocol does not allow
> for these queries whatsoever. This does make the protocol itself
> simpler, but it comes at the cost of combining a significant number
> of responsibilities into one program, which were previously handled
> separately.

Maybe in the beginning that was true, but today it is not.

There are multiple stand-alone compositors that can be integrated into
desktop environments. River[1], Miriway[2], and Wayfire[3] are three
good examples, and two of them (Miriway and River) are designed to be
integrated into a larger experience. River gives you a similar
architecture to X11 where you can write a window manager that
leverages the River Wayland server, and Miriway is designed as an
extensible and configurable compositor built on Mir.

It is far easier today than it ever was before to make a Wayland-based
environment.

[1]: https://isaacfreund.com/software/river/
[2]: https://github.com/Miriway/Miriway
[3]: https://wayfire.org/

--
真実はいつも一つ！/ Always, there's only one truth!

[CS Sushi Man]

> It is far easier today than it ever was before to make a Wayland-> based
> environment.
>

As far as I know, these projects, only handle window state, and
perhaps DRM KMS as well. Since I do not have the time to dig into
these projects' respective documentation, I can only surmise to the
following:

Pixmap-equivalent objects still have to be handled by the
compositor developer, and as far as I know, draw calls also have
to be handled by the compositor developer. The compositor developer
basically has to be a graphics programmer, if they want their DE to
be GPU-accelerated (via merely copying and drawing rectangles). Or,
they will have to use a library like Raylib.

Fortunately, wlroots has a rendering abstraction, so some of
these concerns can be abated. However, I don't know whether the
abstractions provided by wlroots are as clean as X11's.

X11 basically handled these concerns from the beginning, and so
all basic X11 applications were GPU accelerated by default, unless
they were SW rendering to a pixmap or something. Of course, fancy
UI features outside of drawing/copying rectangles and text, still
required an X11 compositor, however, X11 still handled the majority
of the complexity in regards to these operations, including the
relevant memory buffers. X11 is basically a 2D GPU raster API +
window handler in one, which makes it very fast at its job, even
today (Wayland compositors are usually fast, too).

I should note that Wayland clients are made more complicated
because of this problem, as well. Thus, UI frameworks, like GTK and
QT, are now required to be more monolithic, and handle more
responsibility within the UI stack as a whole. These UI stacks were
already complicated enough.

Basically, the maintenance of graphics layers within Linux's UI
desktop software, has been split across several projects, when this
maintenance used to only be in one spot, as far as I know. Due to
this, I believe that the maintenance of this software will become a
significant problem in the near future, for *both* X11 *and*
Wayland.

Sent with Proton Mail secure email.

On Tuesday, June 30th, 2026 at 13:55, Neal Gompa  wrote:
> On Tue, Jun 30, 2026 at 1:14 PM CS Sushi Man via devel
>  wrote:
> > > Speaking of the future: How much effort do we (does someone) want to put
> > > into a DE which requires an X11 stack?
> >
> > It is far easier for a DE developer to maintain an X11 DE, since
> > they would only have to be concerned with having certain pixmaps
> > and rectangles drawn to the screen (like a titlebar), and some
> > input handling (like pressing the close button on a window).
> > Wayland on the other hand, requires a DE developer to maintain
> > their own compositor, which may also include dealing with GPU
> > memory management, handling rendering calls, handling input devices
> > directly, and things of that nature. The "DE" would now have to
> > store window locations, handle BLIT operations, handle the mouse,
> > handle display planes, framebuffers, and everything related. Pretty
> > much, the DE would now have to handle all the things previously
> > handled by the X server.
> >
> > It is *far* easier to maintain an X11 DE, than it is to maintain
> > a Wayland DE/compositor. The DE maintainer, with X11, is only
> > concerned with how the user may interact with his machine, and to
> > forward those interactions to the X11 server accordingly. The DE
> > does not have to store window locations, mouse locations, or
> > anything of the like, since the DE can simply query them from the
> > server. The DE does not have to manage GPU memory, since X11 does
> > this for you via pixmaps. X11 will also handle BLIT operations, and
> > rectangle copies/draws.
> >
> > With the Wayland protocol, the DE maintainer would be required to
> > make his own compositor, since the Wayland protocol does not allow
> > for these queries whatsoever. This does make the protocol itself
> > simpler, but it comes at the cost of combining a significant number
> > of responsibilities into one program, which were previously handled
> > separately.
>
> Maybe in the beginning that was true, but today it is not.
>
> There are multiple stand-alone compositors that can be integrated into
> desktop environments. River[1], Miriway[2], and Wayfire[3] are three
> good examples, and two of them (Miriway and River) are designed to be
> integrated into a larger experience. River gives you a similar
> architecture to X11 where you can write a window manager that
> leverages the River Wayland server, and Miriway is designed as an
> extensible and configurable compositor built on Mir.
>
> It is far easier today than it ever was before to make a Wayland-based
> environment.
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> --

[EXTERNAL] Re: Call for help: Future of the Fedora i3 Spin in Fedora Linux 45

[Przemek Klosowski]

On 6/30/26 3:14 PM, CS Sushi Man via devel wrote:
> Basically, the maintenance of graphics layers within Linux's UI
> desktop software, has been split across several projects, when this
> maintenance used to only be in one spot, as far as I know. Due to
> this, I believe that the maintenance of this software will become a
> significant problem in the near future, for*both* X11*and*
> Wayland.

X11 is far from a Camelot of unity you seem to associate with it. 3d 
acceleration was absent by design, and had to be handled by OpenGL.  The 
compositing effects were handled by double-tripping. The security model 
is really questionable... etc. etc.

There are many reasons why Wayland has the momentum now, and X11 is in a 
stasis. There have been attempts at restarting development of Xfree 
servers, but as far as I know they are struggling. If you truly care 
about graphic subsystem development, I'd advise you to identify the gaps 
and attempt to address them IN WAYLAND: for instance, people miss the 
multi-window statefullness and ability to re-constitute complex 
multiwindow layouts... or the issue of middleware libraries you mentioned.

[EXTERNAL] Re: Call for help: Future of the Fedora i3 Spin in Fedora Linux 45

[CS Sushi Man]

On Tuesday, June 30th, 2026 at 15:41, Przemek Klosowski via devel  wrote:
> and attempt to address them IN WAYLAND: for instance, people miss the
> multi-window statefullness and ability to re-constitute complex
> multiwindow layouts... or the issue of middleware libraries you mentioned.

At what point would Wayland simply become a second, distributed
version of the X11 protocol by adding these features? Each protocol
has their downsides, and upsides. Why should I improve Wayland
compositors for instance, rather than create a new protocol from
scratch, along with a reference implementation, that way, these
problems can be avoided from the start? I don't know if adding to
this complexity, and making each individual client/DE more
monolithic, would be part of my personal plans.

This is getting to be too off topic. I think a new email thread
should be started somewhere (although I don't really know where).
I'm not willing to get smote again by the Fedora gods.

Sent with Proton Mail secure email.

[EXTERNAL] Re: Call for help: Future of the Fedora i3 Spin in Fedora Linux 45

[CS Sushi Man]

On Tuesday, June 30th, 2026 at 15:41, Przemek Klosowski via devel  wrote:
> multi-window statefullness and ability to re-constitute complex
> multiwindow layouts...

Also, can you please detail these features further? I would like
to get a baseline of what is expected out of UI libraries, so that
if I chose to write one, I'll know what to add. Thanks.

Sent with Proton Mail secure email.

[EXTERNAL] Re: Call for help: Future of the Fedora i3 Spin in Fedora Linux 45

[Justin Wheeler]

Folks, this conversation is about *the Fedora i3 Spin*. An endless debate
about X11 vs. Wayland is not relevant here. If you are someone passionate
about either stack, this is a great opportunity to get involved and
contribute to keeping it alive. Otherwise, please take the X11 vs. Wayland
discussion to a user forum somewhere else, as it is not relevant to the
original topic in this thread. Thanks.

On Tue, Jun 30, 2026 at 4:51 PM CS Sushi Man via devel <
[e-mail]> wrote:
> On Tuesday, June 30th, 2026 at 15:41, Przemek Klosowski via devel <
> [e-mail]> wrote:
> > multi-window statefullness and ability to re-constitute complex
> > multiwindow layouts...
>
> Also, can you please detail these features further? I would like
> to get a baseline of what is expected out of UI libraries, so that
> if I chose to write one, I'll know what to add. Thanks.
> Sent with Proton Mail secure email.
>
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it:
> https://forge.fedoraproject.org/infra/tickets/issues/new

[EXTERNAL] Re: Call for help: Future of the Fedora i3 Spin in Fedora Linux 45

[Michael J Gruber]

Justin Wheeler venit, vidit, dixit 2026-07-01 02:30:51:
> Folks, this conversation is about *the Fedora i3 Spin*. An endless debate
> about X11 vs. Wayland is not relevant here. If you are someone passionate
> about either stack, this is a great opportunity to get involved and
> contribute to keeping it alive. Otherwise, please take the X11 vs. Wayland
> discussion to a user forum somewhere else, as it is not relevant to the
> original topic in this thread. Thanks.

Exactly.

I may have triggered this with my remark on X11, whose sole intent was:

How long are we ging to support the X11 stack as necessary for i3?
It's relevant because it might become a technical liability for anyone
wishing to maintain i3, probably shared with other folks wishing to
maintain X11-dependent packages.

Michael
> On Tue, Jun 30, 2026 at 4:51 PM CS Sushi Man via devel <
> [e-mail]> wrote:
> > On Tuesday, June 30th, 2026 at 15:41, Przemek Klosowski via devel <
> > [e-mail]> wrote:
> > > multi-window statefullness and ability to re-constitute complex
> > > multiwindow layouts...
> >
> > Also, can you please detail these features further? I would like
> > to get a baseline of what is expected out of UI libraries, so that
> > if I chose to write one, I'll know what to add. Thanks.
> > Sent with Proton Mail secure email.
> >
> > devel mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/[e-mail]
> > Do not reply to spam, report it:
> > https://forge.fedoraproject.org/infra/tickets/issues/new
>
> -- 
> *Justin* (*he/him*) || 📧 [e-mail] || 🔗 jwheel.org
> TZ=America/Atlanta (UTC-4) 🕗
> *Fedora is a registered Digital Public Good
> https://app.digitalpublicgoods.net/a/12003*
>
> While I may be sending this email outside my normal office hours, I have no
> expectation to receive a reply outside yours.

[EXTERNAL] Re: Call for help: Future of the Fedora i3 Spin in Fedora Linux 45

[Justin Wheeler]

Hi all,

To close the loop here, both @defolos and @x3mboy reaffirmed ownership of
i3 packaging and Spin curation for the F45 Release Cycle[1]. The migration
from Pagure.io to Forgejo is now beginning[2]. So, for the foreseeable
future, the i3 Spin will continue to produce ISOs at or around Fedora
Release Days each cycle. Thanks @defolos and @x3mboy for taking up the
responsibilities! 🙏🏻🎉

@Michael: A conversation about the longevity of the X11 stack as a whole is
off-topic for this thread. It would be a better discussion to have on-list
in a different thread. Based on what both Dan and Eduard said, the implicit
understanding is that as long as Fedora ships X11 as an available package,
the work will continue for i3 packaging and curating the i3 Spin. Eduard
already mentioned in the Fedora Discussion topic that he has some ideas for
improvements to work on in the Spin. If Fedora no longer packages X11, I am
sure everyone involved will revisit the situation then.

[1]
https://discussion.fedoraproject.org/t/call-for-help-future-of-the-fedora-i3...
[2] https://forge.fedoraproject.org/forge/forge/issues/641

On Wed, Jul 1, 2026 at 5:40 AM Michael J Gruber 
wrote:
> Justin Wheeler venit, vidit, dixit 2026-07-01 02:30:51:
> > Folks, this conversation is about *the Fedora i3 Spin*. An endless debate
> > about X11 vs. Wayland is not relevant here. If you are someone passionate
> > about either stack, this is a great opportunity to get involved and
> > contribute to keeping it alive. Otherwise, please take the X11 vs.
>
> Wayland
> > discussion to a user forum somewhere else, as it is not relevant to the
> > original topic in this thread. Thanks.
>
> Exactly.
>
> I may have triggered this with my remark on X11, whose sole intent was:
>
> How long are we ging to support the X11 stack as necessary for i3?
> It's relevant because it might become a technical liability for anyone
> wishing to maintain i3, probably shared with other folks wishing to
> maintain X11-dependent packages.
>
> Michael
> > On Tue, Jun 30, 2026 at 4:51 PM CS Sushi Man via devel <
> > [e-mail]> wrote:
> > > On Tuesday, June 30th, 2026 at 15:41, Przemek Klosowski via devel <
> > > [e-mail]> wrote:
> > > > multi-window statefullness and ability to re-constitute complex
> > > > multiwindow layouts...
> > >
> > > Also, can you please detail these features further? I would like
> > > to get a baseline of what is expected out of UI libraries, so that
> > > if I chose to write one, I'll know what to add. Thanks.
> > > Sent with Proton Mail secure email.
> > >
> > > devel mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> > > Fedora Code of Conduct:
> > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines:
>
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
>
> https://lists.fedoraproject.org/archives/list/[e-mail]
> > > Do not reply to spam, report it:
> > > https://forge.fedoraproject.org/infra/tickets/issues/new
> >
> > --
> > *Justin* (*he/him*) || 📧 [e-mail] || 🔗 jwheel.org
> > TZ=America/Atlanta (UTC-4) 🕗
> > *Fedora is a registered Digital Public Good
> > https://app.digitalpublicgoods.net/a/12003*
> >
> > While I may be sending this email outside my normal office hours, I have
>
> no
> > expectation to receive a reply outside yours.