i3 FAQ - Individual question feed

i3 FAQ - Individual question feedhttps://faq.i3wm.org/questions/Frequently asked questions and answers about the i3 window managerenCopyright i3, 2012Sat, 29 Jun 2013 17:41:54 +0000Why is $patch not merged and made optional?https://faq.i3wm.org/question/778/why-is-patch-not-merged-and-made-optional/Sometimes, there are patches on the mailing list (or elsewhere) which are not merged into i3. Why can’t we have them optionally? Here is an example: http://thread.gmane.org/gmane.comp.window-managers.i3.general/729/focus=744Tue, 20 Nov 2012 10:54:37 +0000https://faq.i3wm.org/question/778/why-is-patch-not-merged-and-made-optional/Answer by Michael for Sometimes, there are patches on the mailing list (or elsewhere) which are not merged into i3. Why can’t we have them optionally? Here is an example: <a href="http://thread.gmane.org/gmane.comp.window-managers.i3.general/729/focus=744">http://thread.gmane.org/gmane.comp.wi...</a> https://faq.i3wm.org/question/778/why-is-patch-not-merged-and-made-optional/?answer=779#post-id-779There are many downsides to letting software grow without any bounds (that is, merging all patches that come up): * More options means longer documentation and more choice for users. While choice is not always bad, the amount of options we have can already be overwhelming. I’d rather have users read all the documentation because it’s short than providing so many options that people cannot manage to read the docs anymore, but two people are happy with their edge cases. * More code paths means more things to test, both automated (where appropriate) and manually. This means more effort for all our developers, which is a bad thing. As an example, I am running i3 with xft fonts on my notebook and with x core fonts on my workstation, just to make sure that both code paths are working fine. * The more different use cases we support, the less clear it becomes what i3 actually is and how it is intended to use. Eventually, it will be able to receive email ;-). I hope that makes my intentions clear when declining to merge patches. I do see that people obviously put effort into their work and obviously have a use-case for it, but because of the above reasons I think it’s better to not merge some patches.Tue, 20 Nov 2012 11:01:19 +0000https://faq.i3wm.org/question/778/why-is-patch-not-merged-and-made-optional/?answer=779#post-id-779Comment by Michael for There are many downsides to letting software grow without any bounds (that is, merging all patches that come up): <ul> <li>More options means longer documentation and more choice for users. While choice is not always bad, the amount of options we have can already be overwhelming. I’d rather have users read all the documentation because it’s short than providing so many options that people cannot manage to read the docs anymore, but two people are happy with their edge cases.</li> <li>More code paths means more things to test, both automated (where appropriate) and manually. This means more effort for all our developers, which is a bad thing. As an example, I am running i3 with xft fonts on my notebook and with x core fonts on my workstation, just to make sure that both code paths are working fine.</li> <li>The more different use cases we support, the less clear it becomes what i3 actually is and how it is intended to use. Eventually, it will be able to receive email ;-).</li> </ul> I hope that makes my intentions clear when declining to merge patches. I do see that people obviously put effort into their work and obviously have a use-case for it, but because of the above reasons I think it’s better to not merge some patches. https://faq.i3wm.org/question/778/why-is-patch-not-merged-and-made-optional/?comment=2113#comment-2113A plugin system is _a lot_ of effort to write and maintain, because it allows people to touch all the corner cases that are not well tested currently. All the reasons I stated in the answer do apply (maybe even stronger) to a plugin system.Sat, 29 Jun 2013 17:41:54 +0000https://faq.i3wm.org/question/778/why-is-patch-not-merged-and-made-optional/?comment=2113#comment-2113Comment by majkinetor for There are many downsides to letting software grow without any bounds (that is, merging all patches that come up): <ul> <li>More options means longer documentation and more choice for users. While choice is not always bad, the amount of options we have can already be overwhelming. I’d rather have users read all the documentation because it’s short than providing so many options that people cannot manage to read the docs anymore, but two people are happy with their edge cases.</li> <li>More code paths means more things to test, both automated (where appropriate) and manually. This means more effort for all our developers, which is a bad thing. As an example, I am running i3 with xft fonts on my notebook and with x core fonts on my workstation, just to make sure that both code paths are working fine.</li> <li>The more different use cases we support, the less clear it becomes what i3 actually is and how it is intended to use. Eventually, it will be able to receive email ;-).</li> </ul> I hope that makes my intentions clear when declining to merge patches. I do see that people obviously put effort into their work and obviously have a use-case for it, but because of the above reasons I think it’s better to not merge some patches. https://faq.i3wm.org/question/778/why-is-patch-not-merged-and-made-optional/?comment=2095#comment-2095why not making plugin system so everybody could be happy ?Wed, 26 Jun 2013 23:27:13 +0000https://faq.i3wm.org/question/778/why-is-patch-not-merged-and-made-optional/?comment=2095#comment-2095