Board index Other Forum

A plea for sanity

Questions about the forum itself, suggestions or issues with the forum software.

A plea for sanity

Postby Thorsten » Sun Feb 08, 2015 7:40 am

It's the magical time of the year when a release candidate is out for testing. The purpose of the exercise is simple. FG has been tested by all the development-minded people who use GIT - but we all have out special use cases, assumptions and so on. So the release candidate should be run by a wider audience, indicating things we have missed so far, unexpected interactions between subsystems such that the problems can be eliminated before the release.

For that reason it's a safe assumption that if the RC has problems, the developers don't experience the largest part of them in their own FG use (because these bugs are already reported during the development phase and mostly gone). So in order to be useful, RC bug reports need to be fairly detailed. In the better case, they're reproducible if a precise sequence of steps is executed, which is why we need to know that sequence. In a worse case, they're dependent on some user-specific settings, which is why we need to know the settings. In the worst case (rendering unfortunately) they occur for a particular driver/hardware combination and are almost impossible to find from afar and require a long interaction with the reporting user, inserting lines into code, re-running and testing.

I'd wish to live in a world where bugs are simple, can be found by just looking at code for a minute and are then eliminated quickly. Alas, usually they're not.

Unfortunately, the truth is also that a large fraction of reported 'bugs' is something else - misunderstandings on how to use options, wrecked configurations by experiments with FG, too ambitious configurations which the hardware can't run properly - i.e. things which affect one user and can be fixed by that user rather than wrong code.

On the personal front, I don't have too much time right now. I have perhaps 1 1/2 hours per day for FG, and I keep spending 2 of those - an hour at least in the forum, trying to sort through bug reports, trying to understand what's genuine, what's lack if information, what's misunderstanding etc. The remaining time I spent trying to follow up bug reports - trying to reproduce, trying to trace the source. The not remaining time I spend arguing on the mailing list. Unlike the typical forum user, I haven't used FG for flying around for two months now - all I get to see is the ufo and the property browser.

For instance fighting for continuing 32bit support. There's been plenty of development on using less memory core-side, but the 2.0 Scenery is so vertex-heavy that it's still hard to fit into 4 GB with everything else and have a decent visibility of more than 20 km. The 1.0 Scenery would still run fine though, its mesh uses a factor ~30 or so less memory, so rather than making the 2.0 Scenery the default and requiring 64bit (as we effectively do now), we could easily make the 1.0 Scenery default and the 2.0 Scenery optional for download, recommended for 64 bit architectures. But people need to be convinced to do that...

Yet, the whole process seems to be flawed on many fronts - everyone waits for someone else to do something.

Here's some actual user responses:

I can't change the weather :/ and more bugs... I will stay with the 3.2 for now. Will wait for the official release...


Well, I did the tests, but will not post results, I will not be the only one to get beaten here, has more than 5 thousand members in the Forum watching and so that others also do tests and post results. I'll cross my arms and stare as virtually everyone is doing.


So, how's that going to fix anything? Even being fed up with the development community - how's that punishing the development community? Remember, we don't see any bugs - we do the exercise for the benefit of the rest of the users. If the rest of the users doesn't participate and gives us the feedback we need, our FG experience doesn't change, but the people who see bugs on the RC will have the same in the release.

What's worse is that finding bugs which I don't see is complicated and (see above) needs more information and interaction, yet many users react affronted when I ask follow-up questions, request more tests and explain that with the current info it's not tracable. Asking follow-up questions costs more time that I don't have, trying to reproduce a bug based on incomplete information costs yet more time.

Combine that with reports which are really feature requests - like 'Could we make a smoother transition between rock and snow?' Or similar - not something that's broken, but something that's not perfect. It's hard enough to deal with the bug reports at RC time - could we perhaps save the feature requests for the time between releases?

Thrown into the fray are the persistent myths, which just get propagated by repetition ad infinitum. FG uses too many resources, the developers don't care because they all have gaming computers. The reality is that the last two release cycles have seen a lot of work making the FG core use less memory - but at the same time, airplane models have had details added, using more memory, and the scenery has become more rich. The way the defaults have been arranged have been... bad (see above..., not that I haven't tried arguing that) so that if you run FG with defaults, it indeed gobbles more memory from version to version. But you can take two minutes to change the settings that your 3.4 looks like your 2.12 and uses a good deal less memory - and that part of the story is never told.

So I spend another chunk of my time trying to tell that part of the story, that people need to make a distinction between core and the data the core is fed and the settings which are used. But nobody wants to hear that part apparently.

To which we can add the Yosemite story - I don't know how many times I have explained to people that FG runs fine on Yosemite, but that they need to switch to a different launcher or do it from the command line.

Let me just ask a few questions:

Why can't the forum moderators make a sticky, prominent topic 'Yosemite problems - read here!'? Why can't we have a sticky 'FG on 32 bit - how to configure memory' topic? (Before you ask back why I never suggested this before - I did - almost a year ago). That'd not fix all problems, but sure as hell lessen them.

And why do people think I should care? I take an hour to argue for 32 bit support and less demanding default distribution, and then get abuse from users who can't be bothered to read through an explanation what causes the memory consumption they're seeing, because they already made up their mind that FG development is on the wrong track and nobody cares? Seriously? Not my idea of fun. Judging by the number of developers posting here regularly or answer bug threads, not anyone else's idea either.

A fair number of users who are complaining that nobody listens to them behave here in such a way that it's very hard to listen to them, and users who complain about how buggy FG is make sure to not give the information to eliminate these bugs. Why would that be? I guess it's much easier to complain than to be part of a solution.

I don't know why all that. I'd like to interact in a forum in which we exchange information in a professional way. I may sometimes want to hang out and chat with people, but not in bug-tracking situations, there I don't want social niceties for which I lack the time, but information to get the job done.

The forum is an offer to you people, and it goes both ways, it's not a service station where you get your wish granted but a place to interact. It can be used reasonably, and then the FG experience will get better. Or it can be misused as a dump for personal dissatisfaction, and then it'll be just that. For the majority of developers, the FG experience will not be worse if the forum is dysfunctional, if users never report problems, if all this becomes a meaningless screaming for attention. Just keep that in mind.

A measure of sanity now and then would be nice here.
Thorsten
 
Posts: 11327
Joined: Mon Nov 02, 2009 8:33 am

Re: A plea for sanity

Postby CaptB » Sun Feb 08, 2015 9:51 am

Bugs happen and you guys are doing some wonderful things giving us FG as free software in this profit driven world, certainly not something to take for granted. There, I had to say it :)
CaptB
 
Posts: 549
Joined: Thu May 23, 2013 6:36 pm
Callsign: EKCH_AP
IRC name: CAPTB
Version: 2018.1
OS: Xubuntu, Win7 64

Re: A plea for sanity

Postby Gijs » Mon Feb 09, 2015 10:09 am

Hi Thorsten,
Thorsten wrote in Sun Feb 08, 2015 7:40 am:Why can't the forum moderators make a sticky, prominent topic 'Yosemite problems - read here!'? Why can't we have a sticky 'FG on 32 bit - how to configure memory' topic? (Before you ask back why I never suggested this before - I did - almost a year ago). That'd not fix all problems, but sure as hell lessen them.

I'm sorry that I missed your request for a memory sticky. I see it's somewhere "hidden" in a discussion, so I probably just skipped over it. Sorry for that. We do have quite an extensive big red box above the post form in most subfora. To me that one is a lot more in-your-face than a sticky. Yet most people don't seem to read it. Maybe you have an idea how we can improve that?

I've just created a sticky in the Mac forum; please feel free to make suggestions. The Mac forum is already full of topics a non-lazy person would read when he finds it doesn't work on his Mac... but, it's worth trying.

For the 32 bit memory one, would you be able to write one yourself? I think you're a lot better informed on the subject than I am. I'd happily stickify your post then ;-)

Cheers,
Gijs
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9386
Joined: Tue Jul 03, 2007 2:55 pm
Location: Amsterdam/Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10


Return to Forum

Who is online

Users browsing this forum: No registered users and 1 guest