hasufell posted on Thu, 10 Sep 2015 18:57:43 +0200 as excerpted: > On 09/10/2015 04:31 PM, Vadim A. Misbakh-Soloviov wrote: >> WE HAVE NO RIGHT TO DICTATE users what they should use and what they >> should not.
@ Vadim in particular: FWIW, some people are much more sensitive to short runs of ALL CAPS than others. To some, ALL CAPS is ALWAYS SHOUTING, while to others (me, apparently you/Vadim), ALL CAPS can also mean emphasis, as long as the run isn't too long. (I do think that most would agree that whole sentences and certainly whole paragraphs in all caps is shouting, and just as uncomfortable to read as shouting tends to be to listen to.) So I've learned (the hard way) to use *stars* or _underlines_ (or for lower levels, /italics/) for emphasis, and only use ALL CAPS when I really do intend to SHOUT, which isn't often. Given that, many will interpret the above as a SHOUTED DEMAND, which probably isn't what you intended, even if you (as I) feel rather strongly about it in general. > You should really either reconsider your understanding of opensource or > start to pay me. hasufell has a point here, particularly when the above is interpreted as a SHOUTED DEMAND due to the all caps. It is said that he who codes, makes the rules, and that really does tend to be the case. Yes, the code is open to others to do with as they wish (including fork, etc, as hasufell suggests), but the coder could have just done something else instead, and it's their time they're taking, often as volunteers, to make it available to you in the first place. Thus, as you'll see, the argument from most supporting the choice position is that it's the package maintainer's choice, that should the package maintainer choose to support both toolkits, particularly in view of upstream specifically doing the same, he should be encouraged to do so. No demands of the maintainer, and the argument would be entirely different, should the maintainer choose not to support both toolkits. (Which, BTW, is why when gentoo/kde temporarily decided not to support turning off semantic-desktop in kde4 any longer, despite upstream kde continuing to support that choice at least thru the kde4 series, I did actually fork the kde ebuilds, maintaining my own patches in ordered to continue to support kde without the semantic-desktop, when gentoo/kde would no longer do so. I even opened a discussion on the desktop list on the topic of trying to get a user supported overlay going, similar to the kde-sunset overlay used for kde3, when it was removed from the tree. However, shortly after I did so, someone in the gentoo/kde project decided they needed the no-semantic-desktop option and were thus willing to support it in the project, so the USE flag was brought back and the overlay discussion could be dropped. No DEMANDING continued gentoo/kde support, despite continued upstream support, and had I DEMANDED it, I believe it quite possible the gentoo/kde project would have voted the other way when the one dev actually decided it /was/ worth supporting, and we'd probably be having to do it in an overlay, today.) But when the maintainer himself is willing to support it, no demands, as others have argued and I agree, gentoo and the gentoo/gtk project shouldn't stand in the way. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
