I think this bug report is an excellent example of how not to interact with your users.
1. Remove a long-existing feature without telling anyone, hidden in a minor update
2. A user reports it in a friendly and informative manner. Persch [dev] closes with a single word "No". That alone should make any user furious.
3. A discussion ensues with someone finally (and understandably) concluding that this was done intentionally. To which Mueller [dev] responds: "Please don't. Please give https://live.gnome.org/CodeOfConduct a read. And
please consider that this bugzilla is not meant to be a discussion forum but
rather a place where actual bugs are kept."
Holy crap, so we are to conclude that it was not done intentionally but it should not be fixed either and that nobody is supposed to complain because the developers' code of conduct states that they always mean well by definition.
4. Another user sheds light on the backstory by pretty much proving this was done on purpose (contradicting Mueller). To which a third developer responds indignantly that the "official" workaround for this issue is sufficient and that the user should head over to the corresponding wiki page and improve the workaround description. He then closes again with a statement about how all devs are well-meaning (just for the added cognitive dissonance I suppose).
What takes the cake: from reading their description, the suggested "workaround" seems to make the whole window transparent, including the terminal text.
I keep coming back to this idea (https://news.ycombinator.com/item?id=5653878) of creating an API that stores the original titles and then just unleashing a GreaseMonkey scripts that compensates for editors that forget <h1> != story.
It makes sense to keep the titles of the original articles. Otherwise you would be open for complete rewording of the title, and passing of comments by poster. Let the content linked to speak for itself.
As for how this happens, I don't know?
Is this a from moderators import title_checking ...
But then Arc is more functional so maybe it is done in code?
I assume that one of the motivations for this guideline is to prevent submitters from editorializing their submissions by altering the original titles (e.g. "Idiotic developers close perfectly reasonable bug report").
> I don't think I agree with the people who seem to think of transparent terminals as massively important feature, though I do find them nice.
I don't like transparent terminals myself but the bottom line is that Linux users spend a lot of time in their terminal. Terminals are the #1 productivity tools for Linux. You just can't remove features from such tools willy nilly without consulting with your users.
If that's their stated goal, then they should just come out with it and let all of the users that spend a good majority of their time in terminals migrate to something else. I have a sneaking suspicion that GNOME usage would take a nosedive if they were to do this.
Honestly I don't think that would happen even if they plainly stated it. At this point the writing has been on the wall for years and yet the "power users" who would care about this still haven't switched. Whether it's Stockholm syndrome, or self-blaming, or "oh, that wouldn't happen to me" I don't know, but it's getting increasing harder to blame the GNOME devs... they've made their opinion very clear and they're the ones driving the ship.
If you're a passenger and you think you see icebergs you need to abandon ship, not whine with the Captain about where to steer.
Perhaps I shouldn't have used "iceberg" as that implies some upcoming inevitable disaster, which I don't think is true of this situation. The GNOME devs could certainly end up very successful.
I happen to disagree with the course, but it's their right as developers to choose a different direction. At some point as a user you have to come to grips with the fact that their vision and yours have diverged. There are undoubtedly many other users who prefer this different direction and they can't all be right.
Find the boat going the direction you want to go and climb aboard and help out.
Really? In when Linus did his talk about git for Google Tech Talks, he explained that the reason they parted ways because many of the linux developers were taking issue to working in a non-libre environment, I seem to recall...
BitKeeper was non-libre for a long time, but they dropped the free-to-the-community version which forced the move. Linus drew criticism for a long time over the usage of a non-libre version control system for the Linux kernel.
I think you have to look at the actual market: Linux is primarily used by people who are power users; I'd go so far as to say that the vast majority of people using Linux are power users, and that the reason they switched to Linux in the first place was specifically because they were power users, and Linux catered to them better.
Now, the best software projects on Linux, ones that had previously been creating software that power users liked, and which became important at all because of the power users that switched over to using it, have apparently decided that power users are a minority segment of the overall market and that they are no longer worth optimizing for.
To make this clear: imagine if Windows, which currently is marketing itself to the "average computer user segment", a user segment that by-and-large were humans with some large subset of eyes, hands, and ears, and decided that the real money in the future was going to be branching out to take over the "any organism of any form" market.
Of course, that market has no real use for a keyboard or a mouse, as the majority of organisms don't have fingers. They can't see the screen, and they probably can't even reason in symbols. So the entire user interface starts getting converted into some kind of EM sensitive yes/no detector that is mostly useful for doing simple arithmetic.
Would this be reasonable? Would the people who currently use Windows not find this ludicrous? This analogy is obviously downright insane, but frankly I think it covers the situation here really well: the people who care about Linux are power users, so by forsaking power users they are forsaking their entire existing market segment.
For a simpler analogy, that I think also nails the core of the problem here while seeming really awkward: imagine if ALL the worlds best manufacturers of semi-trucks decided that cars were more profitable, and so decided to start marketing their products to them, not just by adding amenities but by making them less useful as semi-trucks.
So, over time, new models stop taking diesel, they force a back seat into the front, they add an optional trunk, and one they they decide to just remove the option to hitch things to the back at all. Would this be sane? This may even make sense on some kind of long-term strategy to take over the car market, but their market doesn't want a car.
Here, then: yes, I would agree with "the terminal is a power-user feature", but it is missing the point entirely to then argue that "I don't see any comment on the number of power users out there" here: claiming something is a power-user feature in order to justify its removal is indicating "small market segment", but power users are the market segment.
"It is designed to put you in control and bring freedom to everybody."
That mantra should not just affect the product, it should be the way the whole project functions too.
How is it freedom if they decide that a feature I use is no longer relevant, necessary, chose to remove it and don't inform me about it? It also doesn't give me control, does it?
The whole behaviour of the devs on that thread is completely in-elegant, so much for that part.
I also fail to see how that mantra excludes users that do spend a lot of time in terminals? Don't we deserve nice and elegant things and to be brought control and freedom? They explicitly state everybody, that includes us terminal mungers.
Makes you think, doesn’t it? (The warnings refer to another bug a few months ago, where I tried to make another developer explain his removals, and good discussion and a full blog post resulted. All in all a good result. But still they said I was out of line because I named names)
Well, I added backstory, which extended two years before this unnecessary public outrage event. People were asking questions about where the code went. I explained there was no clear single commit and how to find where it was removed.
And then I overstepped and deduced that this may be assumed to be intentional, condering the backstory.
You might say that was inappropriate and I was banned with justification. But I’m a human too and this lack of proper communication frustrates me to no end. If the developer in question can be said to have a breaking point, I have one too.
None of this would have happened if the involved parties had a better standard of communication and of handling matters.
I stand corrected. However, Tobias Wolf shows that it was indeed intentional. Which makes sense to me as an outside observer, because if it wasn't intentional then why close it pertly as WONTFIX, why not just come out and say that this feature was scheduled to be removed?
It is obvious that the removal of the feature was intentional. This easily justifies closing a bug as WONTFIX. Whether or not this was intentionally done in a particularly nasty/hidden way is not obvious, and while the commenter claimed that it was intentional, there is little proof, and even if there was proof, it wouldn’t change anything, hence why he was pointed at the CoC.
Past two years? Gnome has been messed up beyond belief for much longer than that. I used to strongly support Gnome, but these days I'm just happy Canonical largely do their own thing with Ubuntu (for now they happen to do stuff that gives me a better environment than Gnome, but I'm ready to jump if they start doing stupid stuff too).
I said "No." once, but it was in a code review, and there was a lot of context involved. It generated a pretty big backlash until I went to the trouble of explaining all of it. In retrospect, it worked out perfectly, because without the backlash, people might not have realized what had been going on.
I was responsible for keeping a LAMP stack running which ran a bunch of tests written by various other people in the larger department. Usually the benchmark would be C++, and that would be kicked off by a shell script, and that shell script would be kicked off by a Python program. Obviously this is pretty crazy already, but this one guy found a way to make it worse.
One day I noticed this machine was running out of disk space. It was also getting bogged down and was starting to swap since something was chewing CPU and memory. I found a benchmark program (one of the C++ binaries) running, and since it never shut down properly, it kept these giant log files open. Since they were still open, the log rotator couldn't reclaim the space.
I filed a bug with the test owner: please make this test not leave these processes behind. He didn't seem to know how, so I just said that you should make sure you've stopped anything you started. He didn't know how to do that either and booked an appointment in my calendar to see me in person (yes, really).
On that day, we chatted, and I told him that syscalls like fork() return the PID of what you started. You can just hang onto it and whack it later. If that process doesn't fork itself to become a daemon (which this one didn't), odds are it will be the value you want when the time comes. If it does fork or whatever, you might be able to get something done with process groups. I had to explain fork, kill, setpgrp, setsid and all of that to someone who was supposedly employed as a systems tester.
A couple of days later, he sent me a proposal for a fix. It amounted to this:
I should point out that this machine would usually run multiple instances of the same test on different machines at the same time. They'd all have the same bin_name, and they all ran as the same user. At best, the script would kill itself. If we weren't so lucky, it would also bring down anything else which happened to match "bin_name", even if it was completely unrelated.
Even though I had shown him the low-level way to do the right thing, he fell back on this scripting monkey approach. I said that was unacceptable, and left him to figure it out.
Months passed. I'm not exaggerating here. It was something like four months later when I heard back from him. He posted a comment to the (still living) code review asking if things were okay now. I loaded it up to see what he had done.
Nothing had changed. It was the same "ps ... xargs kill -9" cruft he wrote originally. He didn't even try to change things. Maybe he was trying to sneak it past me and wanted to see if I'd forgotten, or didn't care, or what.
Well, given that his question was "is this okay now", my answer to the review was just: "no.". I was no longer interested in elaborating and spoon-feeding him.
He obviously didn't like this, because a few minutes later I had mails from both his boss and my boss saying how I needed to be more constructive and all of this.
I wasn't about to take this lying down, so I found all of our old communications where I tried to teach him how to do his own job: job control stuff fork, kill, and the like. I mentioned all of the back and forth we had and the time I had taken to explain it in person. I even dug up the example code I had written to demonstrate exactly what a session leader or process group winds up doing in practice.
I pasted all of this into the code review, making it public record for the entire company to see. The managers backed off and apologized to me.
A couple of weeks later, he disappeared into some other department.
Christian Persch replied No, which has made people angry. rachelbythebay also replied No and made people angry, but provided background to explain it. Although the circumstances seem different on the surface, I found it to be an instructive narrative.
You nailed it. The point of my story was that there may be more going on which isn't evident from this response. I don't agree with what's apparently happened here, but we don't have the whole story, either.
Full disclosure: I have no horse in this race. I use fluxbox and eschew all "desktop environments" on Linux.
So basically, a junior dev came to you for help because he didn't understand how to solve the problem, you spent a lot of time showing off how much you knew about the subject but didn't actually help him solve it, then he went back and struggled on it for months, still couldn't figure it out, and finally got transferred to a different department. This sounds to me like you being unhelpful and condescending towards someone less experienced than yourself.
Hardly. It was his job to resolve the issue, that's what he was employed to do. That wasn't Rachel's job, and in fact she went out of her way to explain to him how to resolve the issue.
What would you have her do? Do the fix herself? If so - phooey to you, that wasn't her job and she shouldn't have done so. If you don't think she should have done the fix herself, then the only other recourse here would be for Rachel to not give any help at all and let them struggle on themselves.
The developer attempted to push out a change that Rachel had already said wasn't acceptable, then made a massive fuss to his managers and attempted to make her look bad. Then Rachel explained, in detail, why she said no - developer got transferred due to his own incompetence. I can't feel any sympathy for that developer!
A friend of mine works on gnome, and I asked him about it. The actual explanation for this is a lot more reasonable:
"Him: OK, I figured out what happened.
It wasn't ideal in terms of commits.
So, we have an old configuration system GConf, and we replaced it with our new one, GSettings, for N reasons.
GSettings was missing a feature for gnome-terminal to implement, so it went without GSettings for a long time, until the 3.8 cycle, when we ported it over with a workaround.
The port wasn't 100% complete, so it landed with the intention of adding feature parity, like with terminal transparency support.
However, after asking our team, we decided it wasn't worth it keeping the support code around for terminal transparency, and dropped it.
It's an unfortunate thing that happened where the reasoning wasn't relayed entirely in commit messages, and you're right -- it was dropped in a seemingly unrelated commit.
But that's after intentions changed -- a broken port to new tech with the intention to fix it, then that changed, and thus it got dropped under the guise of "Remove dead code"
me: fair enough.
so the only wrongdoing really was persch's response.
Him: Yeah. So, it turns out that he was just tired.
That was the 7th or 8th bug report about it, and he didn't feel like explaining it again."
So, the moral of this story is "communicate clearly the first time or you're going to end up having to communicate clearly about seven or eight times."
That said, I don't understand why he felt he had to keep explaining it. He could have just copied and pasted the answer or closed the bug as a duplicate of the original one that reported the bug. In the original he could have posted a kind explanation about it, and linked to it from the duplicates that followed.
I understand what it's like to get tired and short tempered. I used to moderate an online community primarily of middle schoolers and high schoolers. But ultimately, you end up hurting the community you're supporting more by not doing things The Right Way™ the first time around. You hurt it even further when you fail to acknowledge that you're tired, short tempered, and should probably just go to bed and deal with it in the morning.
Maybe I just expect adults to behave like adults, but "he didn't feel like explaining it again" doesn't float with me as a valid justification for how he handled the issue. It would have taken a comment and a link to deal with it the correct way. Live and learn, sure, but the attitude reflected in his response appears (to me, at least, with my limited visibility) to be reflective of a systemic attitude surrounding GNOME development. And that's no good.
I was going to recommend "closing as a dupe" as well. One nice thing about that is it makes it very easy to see which bugs are causing anguish with the users.
Also it makes it clear which single point of discussion contains the rationale for the changes so that the developer doesn't have to re-explain (something to which I'm sensitive myself, having been on the dev end of changes like this).
Close-as-duplicate is the right answer, though there's a special place in hell for people who close-as-dupe without referring to which ticket is the dupe. In my previous role as a software tester, there'd be all sorts of tickets closed-as-dupe, yet I couldn't find them. Turns out that they had no common search terms and were (usually) not actually dupes, just that the coders didn't want to think too hard on the issue. I'm fine with "won't fix" or pushing to backlog, but let me see what the dupe is.
I just searched for a few different mutations of the phrase "background transparency" in their bugzilla and didn't see any. I was expecting this to be a case of an end user not taking the time to see if their issue was already in the bug tracker, but if it's in there, it's hard to find. If there were really multiple bug reports (which I'm not saying there weren't) then bugzilla has a pretty bad search feature.
It's a pretty big problem when bug trackers are exposed to a group of non-technical users. Stackoverflow has a nice feature where it does a real time search of existing questions as you type yours in to prevent duplicates. I wish that was a considered a must-have feature of bug trackers.
You have to use an advanced search to find NOTABUG, WONTFIX, and DUPLICATE and similar bugs. Otherwise you turn up empty.
There’s even more discussion in the other bugs. For some reason they didn’t dup all those bugs consistently. Maybe that would’ve lead to a criticla mass. But who knows why not.
I'm that friend. I said to Jonanin: "If you want to know exactly, it's a lot of very, very tricky code that's easy to get wrong, hard to get right, and even when it looks like it's working, there's a large perf cost if it's not 100% right.", but it seems he didn't paste that part of the chatlog.
I can't speak for why Christian Perch spoke the way he did, but he knows that he shouldn't do it anymore.
So, let's go into more details. There are a few ways to get real transparency for windows under X.
First of all, there's _NET_WM_OPACITY which is handled by the compositor window manager, and that's the replacement workaround suggested, but some think it's not appropriate enough. Fine.
Second, there's "psuedotransparency", which is expensive on a modern system. Basically, you copy parts of the root window, excluding your window, and then paint it under your window. Every time some other window updates, you need to re-fetch contents. This is wasteful, but it's how transparent terminals were implemented in the 80s. To implement it, there's a bunch of MMX (yes, MMX) code that's been copy/pasted to every project. The only existing program that uses pseudotransparency that's still maintained is XChat/HexChat.
Third, there's RGBA visuals, which require a compositing window manager. The issue here is that the RGBA visual isn't always around: it's dependent on your window being redirected to an off-screen pixmap. If the compositing WM restarts, or you close down the compositing WM and start up a traditional WM, or close down the traditional WM and start up a compositing WM, you have to basically close your window and re-open it. This is racy and bad to do at WM startup time, and accounts for a few bugs/crashes in the WM or in gnome-terminal. Furthermore, closing and restarting the window means that the new window is now on top of the stack whenever you restart the WM.
It's really ugly behavior all around, and we did an informal poll and found that almost nobody was using transparent terminals, and decided to drop the code.
| First of all, there's _NET_WM_OPACITY which is
| handled by the compositor window manager, and that's
| the replacement workaround suggested, but some
| think it's not appropriate enough. Fine.
This is the part that I don't understand. The whole point of 'terminal transparency' is to make the background transparent while leaving the text opaque. This 'workaround' makes everything transparent, which defeats the purpose of leaving the text readable.
I don't personally use terminal transparency, but it does not seem logical that someone could see _NET_WM_OPACITY as a replacement for this. This seems like a really weak (and poorly thought out) attempt to 'throw a bone' to the people that want the feature that's being removed.
Sure, we're removing the NY strip steak from our menu,
but there's always the hamburger, that has beef in it
too. You can even add steaksauce to the burger!
That's what we did with Konsole for KDE 4. KWin integrated compositing with a software fallback in case GL wasn't available, so there was simply no need to maintain the KDE 3.5-era fake transparency.
Nowadays GNOME Shell simply requires a compositor, or so I thought, so it seems like you could assume one is present.
The one issue is supporting the case of running gnome-terminal from non-GNOME environments that also don't have a compositor, but I think it would be fair to give up entirely on supporting that use case.
However you might still want to handle the case of the compositor crashing (I think one of the dev's comments in this thread mentioned that), which is admittedly going to be annoying since it involves dealing with X.
We'd love to do that, but sometimes it doesn't work that way. If you restart the compositor, in order to not crash, you need to unmap and remap your window with a different visual. So the code needs to be there anywhere if your compositor WM doesn't crash.
| Also, making a poll in your 50 people IRC channel
| is not a very meaningful sample size is it?
They just polled the IRC channel? Really? That just seems like the definition of a 'circle jerk.' Was the assumption that all or a majority of users technical enough to use the terminal would be in the IRC channel?
The old code didn't work after the port to GSettings. It crashed in weird places. That's why it was "#if 0"'d around in the GSettings port commit. As I said, the original intention was to fix it, but minds were changed.
With hindsight, yes, we'd love to do things differently. Saying "you should have done" doesn't really help the current situation here.
The gsettings port broke stuff and reintroduced problems. It was long overdue. This means that cutting features to get things out of the door might happen.
If I had to guess without debugging, I might guess that the 'changed' signals were firing at different times in comparison to when the slider was being adjusted that means that changing the background wasn't ordered 100% correct. The code stems back to 1996 -- it's possible that assumptions like these are being made.