Looking for a maintainer

[Airblader]

For various personal and career reasons it will be difficult for me to maintain i3-gaps going forward, despite this already being focused solely on merging (the few and in between) upstream changes, see #417.

For this reason I'm looking for someone who would be willing to contribute their time to take part in this role (or take it over). Essentially, there are three responsibilities attached to this:

1. Merging upstream changes from i3 into i3-gaps (and if necessary resolving conflicts).
2. Releasing i3-gaps when there is an i3 release.
3. Managing GitHub issues (which are raised extremely rarely).

Of course I'll do my best to assist with these tasks.

Anyone who feels up to this task, please do let me know. Note that due to the popularity and user base of i3-gaps I will only consider people who have a proven track record in the open source community.

---

This does not mean that I am immediately abandoning i3-gaps or anything of the sort. But it will be more difficult for me to build and test i3-gaps simply because I will no longer be using it myself.

[Airblader]

@orestisfl @kgilmer Your names pop into my head as obvious candidates here. I certainly don't want to push anyone, but if this is something you'd be interested in doing please let me know.

[kgilmer]

My current open source work is consuming all of my available time. Regolith has benefited greatly by your work and the existence of i3-gaps, but I don't have the capacity (nor probably, the objective perspective) to commit that the project certainly deserves. :pray:

[sdatko]

Out of curiosity, is there no chance for the upstream i3 project to adopt the gaps patch into official mainline? I am not aware of the project history here, but to my understanding, unless gaps are enabled explicitly in config, this shouldn't be a breaking change for the upstream project, right?

[Airblader]

@sdatko It's a fair question, and has been askwed & answered many times in the past. But this seems like a good place to explain it again as well.

Historically, gaps were not accepted in upstream because they did not fit the look & feel of i3. We eventually decided to forfeit this view based on the clear popularity & demand for i3-gaps. However, the way the gaps are implemented is really more of a hack than a proper implementation. It works well enough, but has constraints and issues. The benefit of this is that it made it easy to keep i3-gaps up to date with upstream i3[1], but the downside is that it simply doesn't live up to the quality expectation we have for i3.

There is https://github.com/i3/i3/issues/3724 which is the umbrella issue to get gaps into i3. However, the work that needs to be done is significant, and I don't think it'll ever happen at this point.

[1] Keeping i3-gaps up to date has always been my primary goal, actually, and the main reason to reject most new features to i3-gaps. I didn't actually create i3-gaps originally, a patch had been floating around back then, but it was never rebased to the latest i3 version at the time. Then I came along, did it, people loved it, so I created this repository and just kind of kept merging the latest changes in, as well as improve things here and there, which ultimately led me to become a contributor, collaborator, and finally maintainer of i3 as well.

[ghost]

@Airblader You doing amazing work btw. Is there any other way to patch original i3-wm to get just the gaps ? Like making it a shell script or daemon and then execute it at startup ? Also 2nd question, I'm not much of a version control pro but... Isn't it possible to create a bot that monitors original upstream commits & auto merge into the desired fork (i3-gaps git repo in this case) ?

[Airblader]

Is there any other way to patch original i3-wm to get just the gaps ? Like making it a shell script or daemon and then execute it at startup ?

I don't believe so, at least I couldn't imagine a way.

Isn't it possible to create a bot that monitors original upstream commits & auto merge into the desired fork

Yes, but only until there are merge conflicts which need to be resolved. That's really the biggest issue, and the biggest risk, since conflicts can range from trivial and obvious to resolve all the way to major work being necessary. The latter, fortunately, only happened once or twice in all these years, but it also happened while I was active in i3 development myself. If that happened now, it could be a blocker for moving forward. The upshot here is that not too much is happening in i3 itself these days either, so that risk has gotten smaller, but all it takes is a change in the "wrong" area of the codebase.

The other manual step is cutting releases. Fortunately it's not too difficult, but I never took the time to adjust i3's script to work for i3-gaps, but rather always did it manually. Perhaps that's one of those things I'll do some day...

You doing amazing work

Thanks!

[Airblader]

I will close this as we now plan to merge i3-gaps with the i3 project for the next release.

[Foxboron]

Great news! Thank you for all your effort the past years @Airblader :)

[corpsouth]

I've enjoyed your contributions to the project as a whole, very solid work man.