On 9/10/15 8:05 PM, hasufell wrote:
> a) the gnome maintainers already said they are not interested in
> supporting it indefinitely (they are the maintainers of gtk+ as well)
Aren't there at least some gtk2-only apps? It seems to me we're not that
close to removal of gtk2 from the tree.
I'm also
On Thu, Sep 10, 2015 at 2:21 PM, hasufell wrote:
> On 09/10/2015 08:15 PM, Daniel Campbell wrote:
>>
>> tldr: If the problem is USE flags, let's talk USE flags. If it's
>> supporting more than one toolkit in general, I see no reason not to
>> let maintainers use their discretion and not force thei
On Thu, Sep 10, 2015 at 2:05 PM, hasufell wrote:
> On 09/10/2015 07:17 PM, Rich Freeman wrote:
>>>
>>> Given the fact that we are short on manpower and that most part of the
>>> linux ecosystem is moving towards gtk3... there has been no good
>>> argument to support a toolkit version - that is (ab
On 09/10/2015 08:15 PM, Daniel Campbell wrote:
>
> To my knowledge, the gtk3 version of spacefm *did* indeed have less
> functionality, at first. I think they're mostly the same nowadays,
> though.
That's why spacefm ebuild did not switch to gtk3 when gtk3 support was
still experimental.
> That
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/10/2015 01:47 AM, hasufell wrote:
> On 09/10/2015 08:21 AM, Daniel Campbell wrote:
>>
>> For me to not support gtk2 in the spacefm ebuild would be
>> providing a package inferior to upstream.
>
> That sounds like spacefm with gtk3 is lacking
On 09/10/2015 07:17 PM, Rich Freeman wrote:
>>
>> Given the fact that we are short on manpower and that most part of the
>> linux ecosystem is moving towards gtk3... there has been no good
>> argument to support a toolkit version - that is (about to be) deprecated
>> - for exotic corner use cases t
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
On Thu, Sep 10, 2015 at 12:57 PM, hasufell wrote:
> 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.
>
> You should really either reconsider your understanding of opensource or
> start to pay me.
>
> Gen
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.
You should really either reconsider your understanding of opensource or
start to pay me.
Gentoo is for the most part GPL-2 and you can fork, change and
re
hasufell posted on Thu, 10 Sep 2015 17:35:53 +0200 as excerpted:
>> Again, I'm saying that maintainers should be free to support multiple
>> versions if they wish to do so. They should not be required to do so.
>> And yes, I do realize that this limits options for users, but they're
>> welcome to
On 09/10/2015 05:41 PM, Alec Warner wrote:
>
> There are lots of topics where I concede that QA has a point and can
> utilize its influence; but 'consistency and usability' are not topics I
> would normally expect them to impose on developers.
>
I am pretty sure tree consistency was the reason Q
On Thu, Sep 10, 2015 at 03:07:16PM +0200, Michał Górny wrote:
> Dnia 2015-09-10, o godz. 08:46:41
> Alec Ten Harmsel napisał(a):
>
> > If upstream gives the option of gtk2 or gtk3, why shouldn't the ebuild?
> > From the "I want a usable system with as little code as possible" and "I
> > want a sy
hasufell posted on Thu, 10 Sep 2015 10:47:26 +0200 as excerpted:
> On 09/10/2015 08:21 AM, Daniel Campbell wrote:
>>
>> For me to not support gtk2 in the spacefm ebuild would be providing a
>> package inferior to upstream.
>
> That sounds like spacefm with gtk3 is lacking anything. It is not.
>
On Thu, Sep 10, 2015 at 11:41 AM, Alec Warner wrote:
>
> On Thu, Sep 10, 2015 at 8:35 AM, hasufell wrote:
>>
>>
>> If this affects tree consistency and usability, then it is not just up
>> to the maintainers.
>
> There are lots of topics where I concede that QA has a point and can utilize
> its i
On Wed, Sep 9, 2015, at 09:17 CDT, Doug Goldstein wrote:
> The following is the proposed news item to inform OpenRC users of a
> change to the init script setup for libvirt 1.2.19 and newer.
+1 Looks good.
signature.asc
Description: PGP signature
On Thu, Sep 10, 2015 at 8:35 AM, hasufell wrote:
> On 09/10/2015 03:10 PM, Rich Freeman wrote:
> > On Thu, Sep 10, 2015 at 8:53 AM, hasufell wrote:
> >>
> >> So we are breaking consistency and introduce maintenance and
> >> configuration complexity, because we want to support a corner case that
On Thu, Sep 10, 2015 at 7:31 AM, Vadim A. Misbakh-Soloviov
wrote:
> I disagree witho you and hasufell.
>
> It *IS* users destiny if they get some stabiity issues because of their
> decision to have gtk2-only or gtk3-only system.
>
> Yes, they can paste bugs about improper toolkit support. Is it b
On 09/10/2015 03:10 PM, Rich Freeman wrote:
> On Thu, Sep 10, 2015 at 8:53 AM, hasufell wrote:
>>
>> So we are breaking consistency and introduce maintenance and
>> configuration complexity, because we want to support a corner case that
>> isn't consistently supported anyway and will not be (becau
On Monday, September 07, 2015 23:37:16 Andreas K. Huettel wrote:
> TL;DR: this is something that only infra needs to care about.
>
> The fact that every dev sees it all the time leads to no end of pointless
> irritation.
+1
Regards,
--
Alex Brandt
Software Developer for Rackspace and Developer
I disagree witho you and hasufell.
It *IS* users destiny if they get some stabiity issues because of their
decision to have gtk2-only or gtk3-only system.
Yes, they can paste bugs about improper toolkit support. Is it bad? Rules says
it should be reported upstream. And all the time Gentoo exist
On 10/09/2015 14:44, Rich Freeman wrote:
> On Thu, Sep 10, 2015 at 8:33 AM, hasufell wrote:
>>
>> So this makes no sense, since it's already an unsupported corner case.
>
> Just what use of Gentoo do you not consider an unsupported corner
> case, which isn't already better supported by some other
On Thu, Sep 10, 2015 at 9:07 AM, Michał Górny wrote:
>
> The happy end result is, sometimes user has choice between 'working
> package' and 'package randomly segfaulting when you least expect it'.
> Of course, it's all hidden nicely under USE=gtk2 and USE=gtk3, so just
> *maybe* if you have the ti
On Thu, Sep 10, 2015 at 8:53 AM, hasufell wrote:
>
> So we are breaking consistency and introduce maintenance and
> configuration complexity, because we want to support a corner case that
> isn't consistently supported anyway and will not be (because that's what
> the gnome team said and most upst
Dnia 2015-09-10, o godz. 08:46:41
Alec Ten Harmsel napisał(a):
> If upstream gives the option of gtk2 or gtk3, why shouldn't the ebuild?
> From the "I want a usable system with as little code as possible" and "I
> want a system tailored to my needs" standpoints, having only one version
> of gtk m
On 09/10/2015 02:44 PM, Rich Freeman wrote:
> On Thu, Sep 10, 2015 at 8:33 AM, hasufell wrote:
>>
>> So this makes no sense, since it's already an unsupported corner case.
>
> Just what use of Gentoo do you not consider an unsupported corner
> case, which isn't already better supported by some ot
On 09/10/2015 08:33 AM, hasufell wrote:
>
> So you are saying for the unlikely case that someone runs gentoo on a
> desktop system where he cannot even compile gcc, llvm and others without
> waiting for 2 weeks or setting up his on binhost, we have to provide a
> backup-path for him, so that gtk3
On Thu, Sep 10, 2015 at 02:33:09PM +0200, hasufell wrote:
> On 09/10/2015 02:25 PM, Rich Freeman wrote:
> >
> > gtk2+gtk3 in RAM at the same time has a higher memory footprint than
> > either one alone. If any package uses one or the other, it will end
> > up being loaded into RAM, so there is pot
On Thu, Sep 10, 2015 at 8:33 AM, hasufell wrote:
>
> So this makes no sense, since it's already an unsupported corner case.
Just what use of Gentoo do you not consider an unsupported corner
case, which isn't already better supported by some other distro?
The whole point of using Gentoo is having
On 09/10/2015 02:25 PM, Rich Freeman wrote:
> On Thu, Sep 10, 2015 at 8:13 AM, hasufell wrote:
>> On 09/10/2015 02:03 PM, Rich Freeman wrote:
>>>
>>> Suppose you want to run on a non-embedded system with limited RAM and the
>>> ability to choose means you can use one of the two libraries
>>> exclu
On Thu, Sep 10, 2015 at 8:13 AM, hasufell wrote:
> On 09/10/2015 02:03 PM, Rich Freeman wrote:
>>
>> Suppose you want to run on a non-embedded system with limited RAM and the
>> ability to choose means you can use one of the two libraries
>> exclusively, thus eliminating the need to load the other
On 09/10/2015 02:03 PM, Rich Freeman wrote:
>
> Suppose you want to run on a non-embedded system with limited RAM and the
> ability to choose means you can use one of the two libraries
> exclusively, thus eliminating the need to load the other library?
> Being able to control what libraries are in
On Thu, Sep 10, 2015 at 6:50 AM, hasufell wrote:
> On 09/10/2015 12:45 PM, Rich Freeman wrote:
>> On Thu, Sep 10, 2015 at 4:47 AM, hasufell wrote:
>>> On 09/10/2015 08:21 AM, Daniel Campbell wrote:
For me to not support gtk2 in the spacefm ebuild would be providing a
package inferi
On 09/10/2015 12:45 PM, Rich Freeman wrote:
> On Thu, Sep 10, 2015 at 4:47 AM, hasufell wrote:
>> On 09/10/2015 08:21 AM, Daniel Campbell wrote:
>>>
>>> For me to not support gtk2 in the spacefm ebuild would be providing a
>>> package inferior to upstream.
>>
>> That sounds like spacefm with gtk3
On Thu, Sep 10, 2015 at 4:47 AM, hasufell wrote:
> On 09/10/2015 08:21 AM, Daniel Campbell wrote:
>>
>> For me to not support gtk2 in the spacefm ebuild would be providing a
>> package inferior to upstream.
>
> That sounds like spacefm with gtk3 is lacking anything. It is not.
> Providing choice f
On 09/10/2015 08:21 AM, Daniel Campbell wrote:
>
> For me to not support gtk2 in the spacefm ebuild would be providing a
> package inferior to upstream.
That sounds like spacefm with gtk3 is lacking anything. It is not.
Providing choice for the sake of choice is not always a good idea.
35 matches
Mail list logo
