ratpoison-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[RP] ratpoison, patches, and the future


From: Jeff Abrahamson
Subject: [RP] ratpoison, patches, and the future
Date: Sat, 27 Dec 2014 22:46:48 +0100

Happy new year (almost)!

TL;DR - I've created an additional public git repository for ratpoison with my patches merged in. (Git is, after all, intended to be multi-homed.) I don't want this to turn into a project fork, but if there's no discussion, that could accidentally happen. This email starts that discussion.

With more text:

I've submitted a number of patches to ratpoison on this list. Most of them haven't made their way into the main source tree, and not because of discussion suggesting they shouldn't. This bothers me on a couple levels. I want to use my own patches. I also want the warm feeling of public credit that comes from seeing my name show up in invocations of "git log". And I'd like to note my contributions to ratpoison on my CV without a reader of my CV thinking I'm lying for lack of mention in the log or the AUTHORS file.

I've pinged Jérémie about this privately, but the conversation didn't start. I assume he's busy rather than ignoring me, and this email is in no way an _expression_ of animosity. So, since I don't have commit privileges to the official repository, I've begun committing to mine. This shouldn't be a problem, git was designed to be multi-homed and to facilitate pulling patches and merging between repositories. I realized recently that I'd slowed down on my contributions to ratpoison because I was concerned that patches would become increasingly difficult to apply if they were all left in a pile for a later date. I'm also concerned that if these become my private patches, I will in essence be running my own private window manager, which is not my goal.

This concern is not entirely theoretical. On the ratpoison wiki, we list a number of patches. Those that have not been applied to the main source tree are sometimes no longer present (links to hosts no longer available) or don't merge cleanly. A patch without a user community behind it is dead code. (This also suggests that the wiki could do with some love.)

The patches I've written are a "git remote add ...; git merge ..." away from being a part of the main tree. I'm open to reasoned discussion that they shouldn't be in the main tree, but not so much to silence.

What I'd like is either to have commit privileges to the main repository or else to have a much more reactive process for applying patches (with "git am" so that contributors get credit in the log).

In the absence of that, I will nonetheless continue to develop and contribute patches, both to this list and directly to my repository. My rough development list is this:

1. Frame affinity (an option). When I close a window, only windows that have some reasonable call to display in that frame should appear. Don't just display the most recently unmapped window.

2. Workspace improvements.

3. Tests. We don't have any, enough said.

4. Performance measurement. We have this ultra-lightweight window manager, we should be able to claim that it's fast and lightweight. But we have no measurements, we have no benchmarks, and this saddens me.

5. Xrandr. When I plug an external display into my laptop, I have to restart ratpoison to detect the external screen. This is a limitation of xinerama, which has largely been replaced in the outside world by xrandr. We should support xrandr.

I want to repeat again that I very much don't want this to become a project fork. We aren't big enough for that (and even if we were, it would seem dumb). The Debian popcon graph for ratpoison suggests 384 installs (not users). By contrast, I3 has 1608, xmonad 1687, notion 116, and cinnamon 1267.

Your thoughts?

Jeff Abrahamson
+33 6 24 40 01 57
+44 7920 594 255    <-- only if I'm in the UK

http://jeff.purple.com/
http://blog.purple.com/jeff/


reply via email to

[Prev in Thread] Current Thread [Next in Thread]