5 ms·

If accurate, this comment by Tobias Wolf is the craziest part: https://bugzilla.gnome.org/show_bug.cgi?id=698544#c19 https://bugzilla.gnome.org/show_bug.cgi?id=

If accurate, this comment by Tobias Wolf is the craziest part: https://bugzilla.gnome.org/show_bug.cgi?id=698544#c19 https://bugzilla.gnome.org/show_bug.cgi?id=698544#c19 "He hid the removal among very unrelated changes (gtk to gsettings switch) and spread the rmeoval across more than one commit. Such that you cannot easily revert it. I strongly assume this was done intentionally."

Tobu 14y ago
It can be reasonable to #if 0 a block of tricky code during a refactoring, just so that you can quickly cross the bridge to a working state. But removing it at that stage will make it impossible for the VCS to track changes to that piece of code, which makes it much harder to restore the functionality afterwards. The RAID/LVM removal from Palimpsest followed a similar pattern (code deleted during a rewrite of an underlying library), but the developer was willing to work on reinstating it. Here we don't really know what Persch thinks — though damn the users is a tempting guess.
johnchristopher 14y ago
It is stated in the previous talk he mentionned that removal of that feature was planned. In they eye of 'Persch' this is not a bug, it is an improvement to GNOME. It's not a bug, it is the removal of a feature. Is a bug tracker really the most appropriate place to discuss in which direction a software is to go ? 'No' and a link to the relevant reason and workaround should be fine in that case but apparently that had already been discussed before (and a reason was given). I don't know if removing it through so much commits is good practice but if the feature was to go it doesn't make a difference in the end, he sculpts his piece of the software any way he likes it as long as it's feeature oriented, right ? Note: I have no advice on wether that feature should have been removed or not in the first place.
- Tobu 14y ago
  By "talk" you mean the link to the "prefs redesign" bug, right? That bug was a good place to discuss which way the redesign would go, but Persch had already decided and made a branch to remove the code.
  - johnchristopher 14y ago
    Yes, that "talk". I might be naive about collaborative software development or the way gnome dev handle things but I think bugtrackers should be about bugs and technicalities, not feature approval or UX discussion if user feedback is wanted otherwise everything that a given user finds annoying would be considered a "bug" and drama would occurs. This "talk" is more shocking in my opinion than the one that made the headline.
- eloisant 14y ago
  Actually I think the line between bugs and new features is thin enough so everything can go to the bug tracker. They're both changes that need to be made, tracked, to get to a better state. Also, inevitably some people in good faith will believe they find a bug when something doesn't work the way they expect it to behave. You can't expect everyone to follow all discussions about features getting cut, so a link to whatever discussion there was (if ever) would have been appropriate.
  - johnchristopher 14y ago
    Wouldn't that be a problem for large projects such as gnome or firefox ? Devs would have to spend some precious time curating the bug tracker issues and explaining decisions and educating users instead of using the bug tracker for its intended use: to track bug.
    - Dylan16807 14y ago
      Would? I'm not sure about gnome but firefox definitely has feature requests and planned features sitting in its tracker, with some of these created by the devs themselves for coordination.
      - johnchristopher 14y ago
        Well... I am naive about collaborative software development :) Do users post to the firefox bug tracker when features are removed like in the gnome case ? How is it handled ?
        shabble 14y ago
        Yep. There's one that bit me recently, where Esc key was previously able to stop GIF animations, and was very handy. Apparently, this behaviour was considered a bug, if a very long-lived one. So a recent update 'fixed' that behaviour, although the justification is stronger there, and the workaround (SuperStop addon[2]) is actually useful, although still on a different keybind (Shift-Esc) [1] https://bugzilla.mozilla.org/show_bug.cgi?id=825486 https://bugzilla.mozilla.org/show_bug.cgi?id=825486 [2] https://addons.mozilla.org/en-US/firefox/addon/superstop/ https://addons.mozilla.org/en-US/firefox/addon/superstop/
- marcosdumay 14y ago
  > 'No' and a link to the relevant reason and workaround should be fine Yes, the original answer is "just" missing the link. As is also the answer to the why comment.
- nirvdrum 14y ago
  Well, the point I suppose is the person filing the issue thought it was a bug. Apparently the removal didn't make any release notes, so why believe otherwise? The reason you have these discussions on the issue tracker is so when the next person comes along to file the issue, he/she now has the relevant context. Randomly guessing at which group to search and post to hardly helps in discovery. If you don't want discussion, disable the comments. But that's hardly conducive to good community teamwork. And I'm really not aware of any project that only uses a "bug tracker." They almost all track issues, ranging anywhere from bugs to new feature requests. Maybe Gnome is different in this regard, but I don't think it's crazy for someone to believe otherwise. Redirecting conversation smacks of a "bugger off" mentality.
VMG 14y ago
The comment is the craziest part, but it is because it is crazy conspiracy mongering, not because it is accurate.
- towolf 14y ago
  There’s no gnome-terminal mailing list. Since "bike shedding" is struck down with regularity on the bug tracker I wrote the guy directly before he made the commits. I asked why he wants to remove the feature. He said it’s loosely connected to other features that are buggy and he doesn’t see the point of the feature anyhow. Whether I had a justification for the feature to stay. I replied and gave him two good reasons, one of personal merit, one of technical merit. Then nothing else. Then I discovered that it indeed had been removed, while I was following git snapshots. So I checked the NEWS and Changelog, ReleaseNotes and git. No mention. Could’ve been temporary or unintentional. So I wrote the guy again to ask what’s up. No reply. Then he replied with a non-answer only pointing to a FAQ entry he made the same day with a distracting workaround. So I checked out git locally to see where the code went. It turned out among unrelated commits where the code was #if 0’ed out only to be removed a few commits later with "delete dead code" etc. So I wrote him again to ask why he did this. No reply. So I downgraded to the known-good old version and waited for release time. Same story repeats with other people. Apparently nothing personal because of my tone. So. Conspiracy or justified puzzlement about this behaviour?
  - bkor 14y ago
    So you felt entitled to publish the personal emails you had with him?
    - towolf 14y ago
      Olav, there were eight bugs filed and no explanation. I came back to the bugs irregularly to see wether there was anything new in terms of explanation. Then this trainwreck happened and people were asking questions. So I thought it worthwhile to add what I knew. I don’t think I disclosed anything personal. It was strictly technical matters relevant to the bug at hand. So why did you ban me with a false accusation? If anything the "removing type-ahead search from nautilus" bug should’ve taught the lesson that an information campaign works better than outright censorship. When that bug got attention Jon McCann came in, explained, and then made a full blog post[1] to expound the directions they were taking. I still didn’t like it but I was satisfied with the explanation. Stop digging in and realize that just slightly amending your policies and interactions with users would fix everything. [1] http://blogs.gnome.org/mccann/2012/08/01/cross-cut/ http://blogs.gnome.org/mccann/2012/08/01/cross-cut/

Tobu 14y ago

It can be reasonable to #if 0 a block of tricky code during a refactoring, just so that you can quickly cross the bridge to a working state. But removing it at that stage will make it impossible for the VCS to track changes to that piece of code, which makes it much harder to restore the functionality afterwards. The RAID/LVM removal from Palimpsest followed a similar pattern (code deleted during a rewrite of an underlying library), but the developer was willing to work on reinstating it. Here we don't really know what Persch thinks — though damn the users is a tempting guess.

johnchristopher 14y ago

It is stated in the previous talk he mentionned that removal of that feature was planned. In they eye of 'Persch' this is not a bug, it is an improvement to GNOME. It's not a bug, it is the removal of a feature. Is a bug tracker really the most appropriate place to discuss in which direction a software is to go ? 'No' and a link to the relevant reason and workaround should be fine in that case but apparently that had already been discussed before (and a reason was given). I don't know if removing it through so much commits is good practice but if the feature was to go it doesn't make a difference in the end, he sculpts his piece of the software any way he likes it as long as it's feeature oriented, right ? Note: I have no advice on wether that feature should have been removed or not in the first place.

Tobu 14y ago
By "talk" you mean the link to the "prefs redesign" bug, right? That bug was a good place to discuss which way the redesign would go, but Persch had already decided and made a branch to remove the code.
- johnchristopher 14y ago
  Yes, that "talk". I might be naive about collaborative software development or the way gnome dev handle things but I think bugtrackers should be about bugs and technicalities, not feature approval or UX discussion if user feedback is wanted otherwise everything that a given user finds annoying would be considered a "bug" and drama would occurs. This "talk" is more shocking in my opinion than the one that made the headline.
eloisant 14y ago
Actually I think the line between bugs and new features is thin enough so everything can go to the bug tracker. They're both changes that need to be made, tracked, to get to a better state. Also, inevitably some people in good faith will believe they find a bug when something doesn't work the way they expect it to behave. You can't expect everyone to follow all discussions about features getting cut, so a link to whatever discussion there was (if ever) would have been appropriate.
- johnchristopher 14y ago
  Wouldn't that be a problem for large projects such as gnome or firefox ? Devs would have to spend some precious time curating the bug tracker issues and explaining decisions and educating users instead of using the bug tracker for its intended use: to track bug.
  - Dylan16807 14y ago
    Would? I'm not sure about gnome but firefox definitely has feature requests and planned features sitting in its tracker, with some of these created by the devs themselves for coordination.
    - johnchristopher 14y ago
      Well... I am naive about collaborative software development :) Do users post to the firefox bug tracker when features are removed like in the gnome case ? How is it handled ?
      - shabble 14y ago
        Yep. There's one that bit me recently, where Esc key was previously able to stop GIF animations, and was very handy. Apparently, this behaviour was considered a bug, if a very long-lived one. So a recent update 'fixed' that behaviour, although the justification is stronger there, and the workaround (SuperStop addon[2]) is actually useful, although still on a different keybind (Shift-Esc) [1] https://bugzilla.mozilla.org/show_bug.cgi?id=825486 https://bugzilla.mozilla.org/show_bug.cgi?id=825486 [2] https://addons.mozilla.org/en-US/firefox/addon/superstop/ https://addons.mozilla.org/en-US/firefox/addon/superstop/
marcosdumay 14y ago
> 'No' and a link to the relevant reason and workaround should be fine Yes, the original answer is "just" missing the link. As is also the answer to the why comment.
nirvdrum 14y ago
Well, the point I suppose is the person filing the issue thought it was a bug. Apparently the removal didn't make any release notes, so why believe otherwise? The reason you have these discussions on the issue tracker is so when the next person comes along to file the issue, he/she now has the relevant context. Randomly guessing at which group to search and post to hardly helps in discovery. If you don't want discussion, disable the comments. But that's hardly conducive to good community teamwork. And I'm really not aware of any project that only uses a "bug tracker." They almost all track issues, ranging anywhere from bugs to new feature requests. Maybe Gnome is different in this regard, but I don't think it's crazy for someone to believe otherwise. Redirecting conversation smacks of a "bugger off" mentality.

VMG 14y ago

The comment is the craziest part, but it is because it is crazy conspiracy mongering, not because it is accurate.

towolf 14y ago
There’s no gnome-terminal mailing list. Since "bike shedding" is struck down with regularity on the bug tracker I wrote the guy directly before he made the commits. I asked why he wants to remove the feature. He said it’s loosely connected to other features that are buggy and he doesn’t see the point of the feature anyhow. Whether I had a justification for the feature to stay. I replied and gave him two good reasons, one of personal merit, one of technical merit. Then nothing else. Then I discovered that it indeed had been removed, while I was following git snapshots. So I checked the NEWS and Changelog, ReleaseNotes and git. No mention. Could’ve been temporary or unintentional. So I wrote the guy again to ask what’s up. No reply. Then he replied with a non-answer only pointing to a FAQ entry he made the same day with a distracting workaround. So I checked out git locally to see where the code went. It turned out among unrelated commits where the code was #if 0’ed out only to be removed a few commits later with "delete dead code" etc. So I wrote him again to ask why he did this. No reply. So I downgraded to the known-good old version and waited for release time. Same story repeats with other people. Apparently nothing personal because of my tone. So. Conspiracy or justified puzzlement about this behaviour?
- bkor 14y ago
  So you felt entitled to publish the personal emails you had with him?
  - towolf 14y ago
    Olav, there were eight bugs filed and no explanation. I came back to the bugs irregularly to see wether there was anything new in terms of explanation. Then this trainwreck happened and people were asking questions. So I thought it worthwhile to add what I knew. I don’t think I disclosed anything personal. It was strictly technical matters relevant to the bug at hand. So why did you ban me with a false accusation? If anything the "removing type-ahead search from nautilus" bug should’ve taught the lesson that an information campaign works better than outright censorship. When that bug got attention Jon McCann came in, explained, and then made a full blog post[1] to expound the directions they were taking. I still didn’t like it but I was satisfied with the explanation. Stop digging in and realize that just slightly amending your policies and interactions with users would fix everything. [1] http://blogs.gnome.org/mccann/2012/08/01/cross-cut/ http://blogs.gnome.org/mccann/2012/08/01/cross-cut/