5 ms·

Wow, I've never had so much of the hard work myself, colleagues, and individual contributors have done misattributed to one company. For those interested in wh

Wow, I've never had so much of the hard work myself, colleagues, and individual contributors have done misattributed to one company. For those interested in what actually was improved, and some attribution for those involved, see https://blogs.gnome.org/shell-dev/2019/11/22/a-review-of-gnome-shell-mutter-3-34/ https://blogs.gnome.org/shell-dev/2019/11/22/a-review-of-gno...

Jasper_ 7y ago
Come on, Christian. Daniel van Vugt at Canonical did a huge number of performance fixes on mutter and gnome-shell this release. Some of those I had to personally vouch for because your colleagues wouldn't land them otherwise.
- audidude 7y ago
  3.34 wasn't a one-person show Jasper. This article reads like it was a one company thing.
  - Jasper_ 7y ago
    Sure, there was a ton of great collaboration, but "mis-attributed" is wrong. Canonical's desktop team definitely lead the charge of compositor performance. Be nice; there's no reason to keep the Canonical/GNOME rift open anymore. They did absolutely fantastic work this release.
    - audidude 7y ago
      And thankfully we've been lucky enough for your important contributions as well.
- traverseda 7y ago
  Can you elaborate on that a little? I've always gotten the impression that gnome is actively hostile to new contributors and anyone who isn't part of the "inner circle", so I'd be interested in hearing more about what that actually looks like, from someone who isn't very anti-gnome.
  - Jasper_ 7y ago
    As someone who went through the pipeline, GNOME is not actively hostile to new contributors, and is actually really friendly, as long as you agree with the overall design and direction of the desktop. In one of the cases, I'd say that what happened was that there were two competing methods for how to fix a performance issue, and some of the maintainers involved were not graphics experts, so I was able to guide the team to determine which version to land, which happened to be the version by Canonical. Canonical's version: https://gitlab.gnome.org/GNOME/mutter/merge_requests/189 https://gitlab.gnome.org/GNOME/mutter/merge_requests/189 Endless's version: https://gitlab.gnome.org/GNOME/mutter/merge_requests/402 https://gitlab.gnome.org/GNOME/mutter/merge_requests/402 This is much more well-understood now that open-source is popular, but it wasn't understood very often back in the day, which is that maintainers have the power to say "no", and do so frequently. If you are a new contributor and you try to change the design, you won't have a great experience.
    - traverseda 7y ago
      I mean sure, but a lot of open source software is driven by the idea that developers "scratch their own itch". It's a bit of a pain that so many patchsets need to be maintained separately for common "scratch my own itch" type features in GTK, instead of the feature just getting buried in a gconf setting somewhere. There are an increasing number of little things in GTK that require you to do things the "gnome way" or maintain separate patch-sets. Any attempt to figure out how we can satisfy both parties gets disregarded pretty quickly. Obvious examples include thumbnails in the file-picker or type-ahead instead of relying on gnome's tracker or slow file-search. I guess there's some subtle difference between "hostility" and "refusal to co-operate with other stakeholders" that I'm not getting.
      - nordsieck 7y ago
        > It's a bit of a pain that so many patchsets need to be maintained separately for common "scratch my own itch" type features in GTK, instead of the feature just getting buried in a gconf setting somewhere. In this case, the pain is in the right place. Mainline needs to be very careful about signing up to maintain new code, especially if it's used by almost no one.
- nushoin 7y ago
  Speaking of whom, anyone knows what's up with Mr. van Vugt? He hasn't been active in GNOME's gitlab in the past month.
simosx 7y ago
Canonical engineer on performance improvements on GNOME for Ubuntu 19.10: https://discourse.ubuntu.com/t/boosting-the-real-time-performance-of-gnome-shell-3-34-in-ubuntu-19-10/13095 https://discourse.ubuntu.com/t/boosting-the-real-time-perfor...
batmansmk 7y ago
I was tempted to try the new Gnome out, but your comment feels like the ecosystem around is full of drama and ego; I'll pass, I'm a pro, I have no time for this.
- Barrin92 7y ago
  I'd recommend you try it out anyhow, as a long time gnome user the performance increase in particular in 3.32 and 3.34 is very noticeable, I've learned just to ignore the drama that seems to accompany these projects.
- noonecares 7y ago
  Not to be a jerk, but literally no one cares that you're a "pro" or that you're choosing not to use Gnome 3. Tens of thousands (likely more) people use Gnome-shell and have never heard of any of this "drama". I guess I'm curious, too, what software do you use if you avoid every single piece of tech that has ever been subject to contention about contribution credit? What a self-aggrandizing stance.
- imesh 7y ago
  How does the drama affect you using the product? I use open source software everyday and have yet to have any open source drama in my life.
  - dx87 7y ago
    Even if the drama doesn't personally affect you, the internal drama can have technical implications, like key developers leaving the project, or forking it and you end up with multiple similar, but incompatible, products. OpenBSD splitting from NetBSD is a an example of that happening.
    - coldtea 7y ago
      Compared to what environment free of "internal drama"?
    - Splognosticus 7y ago
reddotX 7y ago
Canonical fixed gnome

Jasper_ 7y ago

Come on, Christian. Daniel van Vugt at Canonical did a huge number of performance fixes on mutter and gnome-shell this release. Some of those I had to personally vouch for because your colleagues wouldn't land them otherwise.

audidude 7y ago
3.34 wasn't a one-person show Jasper. This article reads like it was a one company thing.
- Jasper_ 7y ago
  Sure, there was a ton of great collaboration, but "mis-attributed" is wrong. Canonical's desktop team definitely lead the charge of compositor performance. Be nice; there's no reason to keep the Canonical/GNOME rift open anymore. They did absolutely fantastic work this release.
  - audidude 7y ago
    And thankfully we've been lucky enough for your important contributions as well.
traverseda 7y ago
Can you elaborate on that a little? I've always gotten the impression that gnome is actively hostile to new contributors and anyone who isn't part of the "inner circle", so I'd be interested in hearing more about what that actually looks like, from someone who isn't very anti-gnome.
- Jasper_ 7y ago
  As someone who went through the pipeline, GNOME is not actively hostile to new contributors, and is actually really friendly, as long as you agree with the overall design and direction of the desktop. In one of the cases, I'd say that what happened was that there were two competing methods for how to fix a performance issue, and some of the maintainers involved were not graphics experts, so I was able to guide the team to determine which version to land, which happened to be the version by Canonical. Canonical's version: https://gitlab.gnome.org/GNOME/mutter/merge_requests/189 https://gitlab.gnome.org/GNOME/mutter/merge_requests/189 Endless's version: https://gitlab.gnome.org/GNOME/mutter/merge_requests/402 https://gitlab.gnome.org/GNOME/mutter/merge_requests/402 This is much more well-understood now that open-source is popular, but it wasn't understood very often back in the day, which is that maintainers have the power to say "no", and do so frequently. If you are a new contributor and you try to change the design, you won't have a great experience.
  - traverseda 7y ago
    I mean sure, but a lot of open source software is driven by the idea that developers "scratch their own itch". It's a bit of a pain that so many patchsets need to be maintained separately for common "scratch my own itch" type features in GTK, instead of the feature just getting buried in a gconf setting somewhere. There are an increasing number of little things in GTK that require you to do things the "gnome way" or maintain separate patch-sets. Any attempt to figure out how we can satisfy both parties gets disregarded pretty quickly. Obvious examples include thumbnails in the file-picker or type-ahead instead of relying on gnome's tracker or slow file-search. I guess there's some subtle difference between "hostility" and "refusal to co-operate with other stakeholders" that I'm not getting.
    - nordsieck 7y ago
      > It's a bit of a pain that so many patchsets need to be maintained separately for common "scratch my own itch" type features in GTK, instead of the feature just getting buried in a gconf setting somewhere. In this case, the pain is in the right place. Mainline needs to be very careful about signing up to maintain new code, especially if it's used by almost no one.
nushoin 7y ago
Speaking of whom, anyone knows what's up with Mr. van Vugt? He hasn't been active in GNOME's gitlab in the past month.

simosx 7y ago

Canonical engineer on performance improvements on GNOME for Ubuntu 19.10: https://discourse.ubuntu.com/t/boosting-the-real-time-performance-of-gnome-shell-3-34-in-ubuntu-19-10/13095 https://discourse.ubuntu.com/t/boosting-the-real-time-perfor...

batmansmk 7y ago

I was tempted to try the new Gnome out, but your comment feels like the ecosystem around is full of drama and ego; I'll pass, I'm a pro, I have no time for this.

Barrin92 7y ago
I'd recommend you try it out anyhow, as a long time gnome user the performance increase in particular in 3.32 and 3.34 is very noticeable, I've learned just to ignore the drama that seems to accompany these projects.
noonecares 7y ago
Not to be a jerk, but literally no one cares that you're a "pro" or that you're choosing not to use Gnome 3. Tens of thousands (likely more) people use Gnome-shell and have never heard of any of this "drama". I guess I'm curious, too, what software do you use if you avoid every single piece of tech that has ever been subject to contention about contribution credit? What a self-aggrandizing stance.
imesh 7y ago
How does the drama affect you using the product? I use open source software everyday and have yet to have any open source drama in my life.
- dx87 7y ago
  Even if the drama doesn't personally affect you, the internal drama can have technical implications, like key developers leaving the project, or forking it and you end up with multiple similar, but incompatible, products. OpenBSD splitting from NetBSD is a an example of that happening.
  - coldtea 7y ago
    Compared to what environment free of "internal drama"?
  - Splognosticus 7y ago

reddotX 7y ago

Canonical fixed gnome