On Thu, 19 Mar 2015 20:45:35 +0000, Orchid Win7 v1 wrote:

>>> Well, maybe they shouldn't actively dissuade people from filing bugs
>>> by making it so sodding hard to file a bug? :-P
>>
>> It *isn't* hard.  I've filed many bugs over the years, and it isn't the
>> oh-so-difficult process you seem to think it is -
> 
> The account setup process seemed tortuously difficult to me. I spent a
> full two weeks trying to work around the problem before I finally gave
> up and tried to file a ticket.

*headdesk*

It seriously is not that difficult.  You go to the site.  You create an 
account, provide information (true or fake information, doesn't matter), 
validate e-mail address, authenticate to Bugzilla, and enter your bug.

It ain't rocket science.

>> based on exactly ZERO experience doing so.
> 
> Zero experience?
> 
> Perhaps you're missing the part where I actually *did* all this to file
> a bug (which, last I checked, is still open). Basically Zypper gives you
> an incorrect error message - but apparently Zypper just tells you what
> Curl tells it. So until Curl gets fixed...

Bug number?

>>> You know what's *really* annoying? Seeing an open bug for THE EXACT
>>> PROBLEM that our production application has, seeing that upstream has
>>> fixed it, and yet OpenSUSE refuses to release an RPM for it. *That* is
>>> annoying! (We're talking about a different bug now. The ticket has
>>> been open for many months. The fix is literally to build a new RPM.
>>> Yet it isn't happening...)
>>
>> Example?  Because for that bug, I'd like to nudge someone, or at least
>> find out why.
> 
> In OpenSUSE 13.1, systemd hangs for 60 seconds on shutdown. It's waiting
> for... I forget what it is now, but after 60 seconds it gives up and
> shuts down anyway. It just means every time you want to shut your PC
> down, you have to needlessly wait 60 seconds before it does it.
> 
> The bug is fixed in systemd 209 (?), but the latest official RPM from
> OpenSUSE is 208, which doesn't contain the fix. (There was some talk
> about the upstream "fix" being a bit of a kludge... I'm not sure exactly
> how true that is. I just want the bug to go away.)
> 
> Somebody filed a ticket. Somebody else said "here, try this RPM and let
> me know if that fixes it". The original poster never let anybody know if
> it worked. Ticket is currently set to "waiting for information" or
> similar.

I didn't see that issue on my 13.1 systems, but now run 13.2, however, if 
the fix is a bit of a kludge, then I can see why the devs wanted to wait 
for a real fix from upstream.

>>>> Not sure what you mean by "show task list option".  What was the
>>>> specific thing you were trying to do?
>>>
>>> The option to have an icon for each window that's open, so you can
>>> instantly switch between windows (or just tell when a hidden window
>>> closes itself). You know, like the Windows taskbar.
>>
>> Oh, like the dash-to-dock extension gives you.  Yeah, that extension is
>> one that I use, and it works great.
> 
> I, too, eventually found an extension that could be configured to behave
> in a suitable manner. It just annoyed me that this is some unsupported
> 3rd-party hack, rather than part of the basic functionality of the
> shell.

Submit an enhancement request, then.  Unless you find logging into a 
website to be a bit too difficult to manage.  The proper place would be 
the GNOME3 bug tracking system (or enhancement request system).

> 
>>> Well, I don't know man. Version 2 of a product has a heap of features
>>> which are gone in version 3. To be, that means that version 3
>>> *objectively* has fewer features. I didn't think there's much to argue
>>> about that...
>>
>> I used GNOME2, and I use GNOME3.  Both did the job I needed, so I don't
>> really care if there are "fewer features", because features I don't use
>> are unimportant to me.  Hence, personal preference.
> 
> I would have thought "seeing what windows are open and moving windows
> around" is a pretty core functionality to a window manager. But
> apparently your mileage is different...

I can see what windows are open, and I can move windows around.  I do 
that every day, so I don't know what you're on about here.

>> So no, you didn't ask for help, yet you complain about not being able
>> to get help.  That's telling.
>>
>>> In seriousness: I asked on Stack Overflow. The question was upvoted
>>> several times, and many other people lamented the utter lack of any
>>> documentation. But nobody actually answered the question. Which is
>>> what happens when nobody knows the answer!
>>
>> One venue, where GNOME development isn't a primary discussion topic,
>> does not mean "nobody knows the answer".  Except in your world, it
>> would seem.
> 
> Stack Overflow is only the single largest place to get help about any
> programming problem you might have. If not one single person who
> happened upon a GNOME question explicitly flagged with the GNOME tag
> knows how to do a thing, it can't be that well-known. (And if it *was*
> well-known, surely there wouldn't be so many people up-voting the
> question. Rather, they'd be saying "dude, read the manual, it's right
> here!")

I'll let you in on a little secret:  Not everyone with expertise has time 
to read a million different forums.  When a project has its own forums, 
use those rather than third party forums.  Choosing an appropriate venue 
is important.

See http://catb.org/~esr/faqs/smart-questions.html for why that's 
important.

>>>> And "deleting code from the running system" isn't the same as
>>>> extending it.
>>>
>>>    From what I've seen, you write extensions by deleting existing
>>>    objects
>>> and replacing them with new ones. (Or maybe just replacing a method or
>>> two.) You'd think it works by creating a new object that exposes a
>>> defined set of operations, and passing that to the framework. But no,
>>> it seems you just put your hands in the framework, rip out the bits
>>> you don't want, and then replace them.
>>
>> Overriding is not the same as "ripping out the bits you don't want and
>> replacing them".  You should know that from your study of OOP methods.
> 
> Thing is, when you override a method, you're not destroying the old
> implementation. You're creating a new class that works differently.
> Anybody using the old class still gets the old behaviour. This is
> different; you're dynamically deleting the code from the system while
> it's still running - potentially even while somebody is trying to *call*
> that code!
> 
> I mean, it *works* and all... It just seems like a pretty scary design.

I don't know for sure, but I think you'll find the underlying code is 
actually still there when an extension is installed - you're just hooking 
around it.

>>> And then watch it all break horrifyingly in the next minor-release of
>>> the shell.>_<
>>
>> If you refuse to find the right venue to ask for help, then you kinda
>> get what you deserve there.
> 
> I'm talking about all the extensions that *other* people wrote which
> break on later versions of the shell. (My own extension actually
> survived - mostly because it barely does anything.)

Well, here's a shock - when you upgrade a piece of software, stuff that 
depends on the software you upgraded might not work properly.  That's 
only the way things are with *every single piece of software used as a 
foundation for some other piece of software on the planet*.

>>> Still, IMHO, I think most of this brokenness goes back to "we decided
>>> to build a huge, complex application in a scripting language". All
>>> problems flow from there.
>>
>> Now there's something I might be able to get behind.
> 
> Somehow I doubt the GNOME foundation are going to change it tho. ;-)

So then the alternative is to deal with it, if you have to, or don't, if 
you don't.
-- 
"I learned long ago, never to wrestle with a pig. You get dirty, and 
besides, the pig likes it." - George Bernard Shaw

Post a reply to this message