Scheduling Client updates.

[Quantum]

Hi Konny/DK

Might I make a suggestion that Client updates are scheduled on a monthly basis. If they were scheduled for maybe the first Saturday or Sunday of the month then we know when to expect them. Client updates should only be published on the expected date AND only if either Konny or DK are available to monitor if any major bugs occur with it's introduction. If Konny/DK are not available then it waits until the following month. It could be done on any day really but ideally Konny should be around to undo any major disasters to VA rep/finances etc immediately should they occur.

Just a suggestion.

Rgds

John

[IslandBum]

Seconded

[FsNovice]

I think this idea is completely unworkable personanlly, this could mean huge delays in getting a new client when konny and dakurt have the creative ideas to work on this great client and flynet solution. I think the current arrangment works fine, although granted v.06 didnt go to plan. Only one minor glitch IMO

[ssanchez]

Agree with the idea.

That way we would know that at the begining of the month the new release will be implemented, and not only one but a couple or more improvements would be implemented at once, instead of one every couple of days.

This would also lighten the load of work for our developers. IMHO

[AK_Dave]

Hi Konny/DK

... to monitor if any major bugs occur with it's introduction.

Frankly, software with major bugs shouldn't be released, even for beta testing. Beta testing should be to find minor bugs. Is there no test server set up where new software can tested for major bugs BEFORE it's released to the FlyNET community for beta testing?

Ideally, you'd have such a test server, or test database. You'd have a group of people who had accounts on that test database in addition to their regular FlyNET accounts. You could then assign flights to test pilots as needed to test software changes aggresively. If you had even 10 or 20 pilots who could each fly a single flight on the test server when a new client is to be tested you'd be able to quickly catch major, and most minor, bugs.

Just a thought. It is, after all, only play money, and play airplanes. And even in real life, businesses sometimes experience cataclysmic events which can put them out of business.

Dave

[BFuller]

Once a month? Bad idea imo. It should be coded and then tested. Once tested, then released. It shouldn't matter how often it's patched as long as it gets tested to insure nothing is broken.

Have a small QA team.

[UKD192]

I don't think a fixed update is really a good idea either. As and when Konny and DK have the time, then it can be released.
All this talk of test servers and the like is asking a bit much for something that is completely free, and is a 0.6x Beta version.
There are still 2 or 3 versions of MSFS that people use, (2k2, 9, X) several versions of FSUIPC (not everyone keeps a paid for current one), and there are many FS add-ons, so I think its a bit much to ask Konny and DK to test rigorously every time.

Rob

[joefremont]

I like dave's idea of setting up a test server where a hand full of dedicated users can give it a final test before it is unleased on the public. Beta does not mean untested, it usually means that all the internal testing is done and its now ready for external testing.

[DanKH]

I don't think a strict releasecyclus is appropriate either, it is by all means not a commercial product that has to serve 24/7

But to establish a test team OTHER than the developer himself would be a very good idea.

I think it is also a matter of taking pride in ones own work. Testing a program thoroughly before releasing will only add to ones self esteem and to others respect.

Numerous releases half tested will only frustrate the users and finally end up with giving the programmer a bad reputation.

So I think (even if it IS freeware) some effort should be taken to test the various changes before releasing.

One major advance would be to make the update optional instead of forced. Then you could ask if any one would try the never version before releasing it to the public.

As it is now we are all forced to be Ginny-pigs.

So take a good advice and point out a few members willing to do some test rides before each release, and for heaven sake make the update optional.

[AK_Dave]

All this talk of test servers and the like is asking a bit much for something that is completely free, and is a 0.6x Beta version.
There are still 2 or 3 versions of MSFS that people use, (2k2, 9, X) several versions of FSUIPC (not everyone keeps a paid for current one), and there are many FS add-ons, so I think its a bit much to ask Konny and DK to test rigorously every time.

Setting up a separate dB can be done for no expense and with little effort on the same machine that is currently hosting the production database (the database we all use when we fly FlyNET). That would be a minimum amount of work for whoever.

The benefits of assembling a group of volunteers who wouldn't mind flying one flight on the test server now and again (a flight for which they would make no money, make no increase in their reputation, etc.) are many. For example:

1. REDUCE the workload on the programmers as far as testing software goes. Let the test pilots fly and report bugs to the programming team.

2. MAXIMIZE the number of different hardware and software environments that new releases of the client are tested in.

3. REDUCE the number and severity of bugs in software upgrades released for general use, thus reducing the frustration for players and the amount of time spent fixing mistakes made to the database (like reimbursing a dozen airlines for multi-million dollar fuel costs as a result of bugs).


How many alpha testers do we need? *shrug* I don't know. We don't want to make the test db too large, but I don't see where having a handful of planes and a handful of airlines (1 handful approx = 6 to 12) with 20- 30 pilots and maybe 1 or 2 routes per airline should be much of a hit on any server. With those kinds of numbers, we might aim to get 10 - 15 test flights on each debugging cycle for upgraded clients. I know, I, for one, would be happy to invest some flying time to test software if it will help.

I know something like this is done with FS Economy. A test environment has been setup (a smaller copy of the FSE database) where coders can test their client upgrades before releasing to production. To date, client updates have been pretty smooth (few or no bugs), and updates to the web interface have been pretty good too (minor bugs quickly and easily fixed).

Well, I seem to be going on and on. I'll quit yapping and prepare to be blasted. LOL.

Love ya all.....happy holidays!
Be safe up there.
Dave

[PedroD]

The 1) 2) and 3) point s from Dave are very important, and I think that have some tester's before the public realease, is a good idea. well, anyway we are all "Beta testers" at this moment, you guys see what I want to say.

At this moment , I bring back my B744, from KJFK, with a 0.64b and work fine, but I still lost money from my previous 2 flights, and alot of money, airplane maintenance costs, personal account negative during 2 flights that I say in other post.

[joefremont]

All the flight reports contain the version number of the client that was used so konny should be able to identify the flights created by 6.5 and back them out.