* Package name : i3-gaps * Version : 4.16.1 * Upstream Author : Ingo Bürk * URL : https://github.com/Airblader/i3 * License : (BSD-3-clause) * Programming Lang: (C, Perl) * Description : i3-gaps – i3 with more features including gaps, smart borders and smart gaps i3-gaps is a fork of i3wm, a tiling window manager for X11. It is kept up to date with upstream, adding a few additional features such as gaps between windows *** Why should it be submitted and differences to the original (vanilla i3): *** i3-gaps is a popular fork of the most widely used tiling wm (vanilla i3), and is used exclusively by many people. It essentially contains a superset of functionalities to vanilla i3, and its gaps and smart border features as well as added i3bar RGBA transparency make it not only more pleasing to use, but easier to distinguish individual window frames without having to resort to colourful window frames and title bars as in the original. It is included on the main repositories of most major distributions right now, and for good reason. *** Maintaining the package: *** I am a regular user and i plan to maintain the package by myself. I will need a sponsor, since i am starting out now. It will also close this RFP bug (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909646)
Hi Socrates. On 2019-06-15 15:11, Socrates Tzagiousis wrote: [...] Why weren't the changes accepted upstream? Is this really a sustainable fork that has sufficient interest? Kind regards and thanks Philipp Kern
Hey, thanks everyone for reaching out. The interest in making i3-gaps available to more people has prompted some discussion between Ingo (the maintainer of the i3-gaps fork, and an i3 core maintainer) and me. The key concern about the i3-gaps fork is code quality: the implementation cannot easily be merged into i3 as-is. One example is that you cannot enable gaps and display title bars at the same time. The intention behind publishing the fork was to make the feature available to people who can live with the lower code quality and restrictions, not to have a long-term sustainable fork. Ingo will outline what needs to be done to get i3-gaps into a mergable state, so that we can eventually bring these features to all i3 users. For the time being, our recommendation is to NOT add i3-gaps to Debian or any other Linux distribution. Instead, if you have time and motivation, please consider helping improve i3-gaps with the goal of a merge. Thank you,
Hi antisocrates, With that in mind, please reconsider your package, antisocrates, and the invitation at hand ☺. I strongly support the view not to add i3-gaps as a separate package, now that it was made clear that there are efforts to get the gaps feature merged. Cheers, Nik
A surprise, to be sure, but a welcome one. Personally, seeing the popularity of vanilla i3 and by extension i3-gaps (which some people prefer aesthetically) in conjunction with the combined userbase of debian and all of its offspring, it became apparent i3-gaps should have been available sooner in debian. If one was to graph the users the users of the debian-family of distributions and every other distribution family out there, it becomes clear that a lot of people might be missing something they are used to using elsewhere (most other big families of distributions have the fork available as can be seen here: https://repology.org/project/i3-gaps/versions ). And a lot of people have real trouble compiling this piece of software from source (mostly new linux users of the debian-derivatives). Therefore since i use debian from time to time, when my gentoo box is occupied compiling for 12 hours straight, it occured to me i should package i3-gaps for debian and therefore all its derivatives to give people easy access. Certainly, a merge is the superior solution and i am glad its actually being considered, but my understanding is that code refactoring/cleaning could take a considerable amount of time, and therefore the package should actually be available as a temporary solution for all those who want to use it, as it currently is everywhere else. Again, i congratulate Michael and Ingo for their work.
being considered, but my understanding is that code refactoring/cleaning could take a considerable amount of time, and therefore the package should actually be available as a temporary solution for all those who want to use it, as it currently is everywhere else. I don’t think having it available temporarily is a good idea. It complicates the situation both for the package maintainers and for end users.
❦ 17 June 2019 18:30 +02, Michael Stapelberg: It seems there is not much progress on this front. The issue on GitHub does not show activity either. As other popular desktop distributions (Fedora, openSuSE, Arch and Manjaro) are providing a i3-gaps package, maybe an i3-gaps package in Debian could be reconsidered? I would gladly sponsor it if there is no strong opposition from i3 maintainers.
I still think it’d be better to spend time on merging gaps rather than packaging gaps, but it seems like nobody has the skill set and/or motivation. Is there someone who would continuously maintain i3-gaps in Debian? I wouldn’t want that package to diverge from upstream i3 in terms of which version is available in Debian. I’m asking in particular because people might switch from X11+i3 to Wayland+sway over the next few years.
❦ 3 October 2021 08:48 +02, Michael Stapelberg: This is a very different skillset from packaging. Alternatively, src:i3-wm could build both i3-wm and i3-gaps. It adds extra work on existing maintainers but maybe you and Jakob would be OK with that? I can propose a patch for that if it helps.
Personally, I don’t want gaps to be built from src:i3-wm. It’s enough work to maintain one version of i3. That said, sur5r is doing all of the Debian work since I retired from Debian, so it’s ultimately up to him. I will stress one more time that what we need here is not a one-time sponsorship offer, but a multi-year commitment for maintaining the i3-gaps package in Debian.
❦ 3 October 2021 09:16 +02, Michael Stapelberg: Let's hear from antisocrates. I can offer a multi-year commitment for sponsorship and take over maintainance if needed. I can also maintain it myself. I suppose you would favor i3-gaps to conflict with i3-wm instead of trying to be co-installable (with or without alternatives as the difference is limited to a few binaries and I think this does not include i3-msg).