Re: migrating gtk

Hi everyone, can we please stop the ad hominems and stick to constructive suggestions to improve things please? this is becoming disgusting and is a poor display of community dynamics Thank you. 2018-02-05 16:36 GMT+01:00 Morten Welinder : > > Your behaviour on this mailing

Re: migrating gtk

> Your behaviour on this mailing list, and on Bugzilla, has been > consistently rude, inconsiderate, and plain abusive of the patience > and effort that volunteers put in the platform you're consuming. You have absolutely no respect for the work of other volunteers to the gtk+ project or for

Re: migrating gtk

On 5 February 2018 at 14:15, Emmanuele Bassi wrote: > I gained the fact that you read your email and if you're still > experiencing the issue, or if it was accidentally fixed in the ~4 > years between your original report and me going through the open bugs > of

[gdbus-codegen] handle property set on the service-side

Hi everyone, I am developing a DBus service with GDBus. To avoid the repetitive and fastidious task of wrapping the dbus signals, properties and method call handling, I am using gdbus-codegen to generate the wrapper from a XML introspection file. I think I might have reached some limitation

Re: migrating gtk

On 5 February 2018 at 13:19, Morten Welinder wrote: >> Considering that you usually stop short of the first step I have to >> ask you: what kind of "busywork" have you ever experienced? > > Here's a sample: > https://bugzilla.gnome.org/show_bug.cgi?id=694627#c7 > > Yes, that

Re: migrating gtk

> Considering that you usually stop short of the first step I have to > ask you: what kind of "busywork" have you ever experienced? Here's a sample: https://bugzilla.gnome.org/show_bug.cgi?id=694627#c7 Yes, that was you. What did you really gain from asking that question, other than verifying

Re: migrating gtk

Hey Matthias, Sounds good. In the short experience with the migration it looks like it worked well to be as strict as possible, meaning, migrating the only the most relevant bugs. I would also take the opportunity to ack/nack pending patches if that is possible for gtk+. Just to double check,

Re: Does GTK+ do automated/nightly performance regression testing?

On 02/05/2018 02:49 AM, Emmanuele Bassi wrote: > GSK has a prototype of a profiling object that should be improved; > Christian Hergert has worked on performance counters for sysprof and > gnome-builder, so we should also look at that. For Sysprof 3.28 we'll be installing a libsysprof-capture-2.a

Re: Does GTK+ do automated/nightly performance regression testing?

On 5 February 2018 at 10:40, Timm Bäder wrote: > On 05.02, Clemens Eisserer wrote: >> So back to the original question: How does the GTK+ project make sure >> to spot performance regressions when they are introduced? >> And if there is nothing automated, would there be interest

Re: Does GTK+ do automated/nightly performance regression testing?

On 05.02, Clemens Eisserer wrote: > So back to the original question: How does the GTK+ project make sure > to spot performance regressions when they are introduced? > And if there is nothing automated, would there be interest in such a > project - Would it be useful and used by the developers

Re: migrating gtk

On 4 February 2018 at 20:52, Morten Welinder wrote: > As a general principle, you should only ask bug reporters to do work if you > intend to do something with the answer. Or, with other words, it really is > not nice to keep asking "is that bug still there?" until they get

Re: Does GTK+ do automated/nightly performance regression testing?

On 5 February 2018 at 09:35, Clemens Eisserer wrote: > Hi there, > > I wonder - is there any automatic / nightly performance regression > testing done against GTK+ development snapshots, like it is done by > other performance-sensitive open-source projects (e.g. mozilla >

Does GTK+ do automated/nightly performance regression testing?

Hi there, I wonder - is there any automatic / nightly performance regression testing done against GTK+ development snapshots, like it is done by other performance-sensitive open-source projects (e.g. mozilla firefox)? The reason I ask is, from a subjective point of view, several times during