[gentoo-dev] Re: www-client/chromium gtk3 support

[Duncan]

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