Bug Reports / Testing Process / Updates?

[GGTharos]

I don't know how to phrase this well ... OB is a good idea. What happened with 1.2.8 may not have been optimal, but keep in mind that despite all good intentions, there will always be some external (or internal?) pressures to finish faster. In that respect, some OBs may go worse than others. It's just a part of business.

 

I won't argue against you but we should not forget that the introduction of the open beta was an improvement.

But IMO it was a failure to finish the 128beta so quick and in a state worse than 1.2.7.

In such a way the open beta is not really needed. So ED could start there to improve the situation and handle the open beta better.

[sorcer3r]

I don't know how to phrase this well ... OB is a good idea. What happened with 1.2.8 may not have been optimal, but keep in mind that despite all good intentions, there will always be some external (or internal?) pressures to finish faster. In that respect, some OBs may go worse than others. It's just a part of business.

 

ED is still working on 1.2.8 so it could still be open beta. No need to "overwrite" the better 1.2.7.

If external pressure could have been that people wanna fly the new FCF15, sling loads etc. they still can download the open beta.

And if internal pressure could have been selling the FCF15 module people could buy it during open beta.

IMO this is why I was looking forward for the open beta because these pressure factors would not have a big impact on stable DCS versions.

But 1.2.8 open beta feels more like a placebo and that is not a good motivation for testing the next beta.

[NineLine]

When you sign on to test something, either us as Testers or you as an Open Beta early adopter.... you take the good with the bad. Open Beta should be approached with the mind set that you want to help test the release, not to get new features early, etc.

 

ED is still working on 1.2.8 so it could still be open beta. No need to "overwrite" the better 1.2.7.

If external pressure could have been that people wanna fly the new FCF15, sling loads etc. they still can download the open beta.

And if internal pressure could have been selling the FCF15 module people could buy it during open beta.

IMO this is why I was looking forward for the open beta because these pressure factors would not have a big impact on stable DCS versions.

But 1.2.8 open beta feels more like a placebo and that is not a good motivation for testing the next beta.

[sorcer3r]

When you sign on to test something, either us as Testers or you as an Open Beta early adopter.... you take the good with the bad. Open Beta should be approached with the mind set that you want to help test the release, not to get new features early, etc.

 

... wich is not in contradiction to what I wrote. (except if I could not express myself properly ;) )

[Dr_Arrow]

When you sign on to test something, either us as Testers or you as an Open Beta early adopter.... you take the good with the bad. Open Beta should be approached with the mind set that you want to help test the release, not to get new features early, etc.

 

Well, the paradox here is that open beta is currently in better state than 1.2.8 release version - as it has received two patches fixing several bugs .... :huh:

[NineLine]

How is that a paradox if open beta is in a better state right now, that is the goal of patches, to make things better, that doesnt mean you push it through right away.

[Dr_Arrow]

How is that a paradox if open beta is in a better state right now, that is the goal of patches, to make things better, that doesnt mean you push it through right away.

 

paradox is that something called beta has less bugs than something called release version, assuming no new ones were introduced of course :)

[NineLine]

paradox is that something called beta has less bugs than something called release version, assuming no new ones were introduced of course :)

 

SO beta should have more bugs than release? Or beta should have the same amount of bugs?

 

Or is it a paradox that you think the Beta should be released because you perceive it to be better than the current release, but in the next statement comment on whether there were any new bugs introduced with the beta, hence the reason its in beta, to see if any new bugs were introduced?

 

;)

Edited May 27, 2014 by NineLine

[Flagrum]

SO beta should have more bugs than release? Or beta should have the same amount of bugs?

 

Or is it a paradox that you think the Beta should be released because you perceive it to be better than the current release, but in the next statement comment on whether there were any new bugs introduced with the beta, hence the reason its in beta, to see if any new bugs were introduced?

 

;)

Paradox is only that we have a 1.2.8 release version and a more current 1.2.8 beta. But that is only nitpicking at formalities.

 

And, while thinking about it, it isn't even paradox ... the current 1.2.8 beta is the beta for the first official patch for 1.2.8 ... :o)

[NineLine]

How is that a paradox though? Sounds like normal development... you have a beta version of the newer 1.2.8 version.... They are asking people to test it before it goes live... not a paradox at all.

[Flagrum]

How is that a paradox though? Sounds like normal development... you have a beta version of the newer 1.2.8 version.... They are asking people to test it before it goes live... not a paradox at all.

lack of coffein .. :o)

 

(i ninja'ed in this conclusion already in my earlier posting :o)

[NineLine]

lack of coffein .. :o)

 

(i ninja'ed in this conclusion already in my earlier posting :o)

 

 

Its ok, sometimes I think you guys try to hard to find fault in ED ;)

 

Is it really so bad here? :)

[Dr_Arrow]

How is that a paradox though? Sounds like normal development... you have a beta version of the newer 1.2.8 version.... They are asking people to test it before it goes live... not a paradox at all.

 

Thanks for your answers Sith, I didn't want to be disrespectful or something against ED - It's just my opinion - but for me it would be more logical to have 1.2.8 beta -> 1.2.8 release -> 1.2.8 release bugfix 1->1.2.8 release bugfix 2->1.2.8 release bugfix 3 ... ->1.2.8 release bugfix n ->1.2.9 open beta->1.2.9 release -> etc.

[NineLine]

It's just my opinion - but for me it would be more logical to have 1.2.8 beta -> 1.2.8 release -> 1.2.8 release bugfix 1->1.2.8 release bugfix 2->1.2.8 release bugfix 3 ... ->1.2.8 release bugfix n ->1.2.9 open beta->1.2.9 release -> etc.

 

 

Maybe if the numbers didnt go farther than 1.2.8. There are five more numbers after 1.2.8... and the fixes in the patches we are seeing dont constitute a whole new version (ie 1.2.X) SO you are getting a beta of a newer version of 1.2.8. Dont over complicate it... its really not that complicated.

[chardly38]

My suggestion is just keep your frustration to a minimum (I myself must take this advice as well) and use your pocket book to show your dissatisfaction.

 

Money talks, People who buy every release simply to support what they "hope" will be released eventually, well I've purchased everything ED has produced and we're no closer to anything I want. I use to be one of those people but not anymore.

 

+1 :thumbup:

:poster_offtopic:

if helios doesnt work with edge then im out. But I know thats not up to ED.:Flush:

[ShuRugal]

This thread might be too far along for my own two cents to attract any useful notice, but I'll chip in an idea anyway:

 

One thing I can think of that would provide the developer team with material benefit in a public-facing bug tracker would be the ability to gather more data about specific bugs.

 

What if, instead of opening the entire tracker on a read-only basis, or establishing a tracker tha the public can feed into wiki-style, we did something a little different:

 

Tracker for designated high-priority bugs. The bugs that go into this tracker would be at the discretion of the devs. The bugs posted to this tracker would then be open for comment by registered users for the purpose of providing information about under what circumstances they encounter the bug, tracks of the bug, and their system information.

 

This would provide a means for the customers to materially contribute to the bug-resolution process, while allowing the devs the discretion to focus their efforts on what the dev team has decided needs priority.

 

And if anyone wants to whine about their bug not getting priority... well, that's no different than what we already have, and it would happen in the same place (on these forums) since posting of bugs to the tracker would be handled by the testing/development teams.

[FSKRipper]

Ok after the last 15 pages and answers to my questions I have no doubt that a lot of work is done behind the curtain.

 

When posting a new specific performance issue in the DCS World section a couple of minutes ago, I noticed how similar some reports are and how difficult it may be for the moderators to keep up in following them. In my opinion it could be less work if the reports are delivered with screenshots or tracks (as the beta forum already demands). When done so, a simple "noticed" report by a tester or moderator would be sufficient to close the thread which would shorten the discussion and keep the Forum more clean and on the topic.

 

Just an idea :music_whistling:

[NineLine]

Yes, you can never post too much info when it comes to all that. When ever you report a bug or issue, post everything you can to help explain it, as well, as a Tester a key element is being able to reproduce the problem. Its not always easy with vague posts.

[ShuRugal]

Yes, you can never post too much info when it comes to all that. When ever you report a bug or issue, post everything you can to help explain it, as well, as a Tester a key element is being able to reproduce the problem. Its not always easy with vague posts.

 

Right, that's what my idea addresses. It'd basically be taking the Beta Forum to the next level and putting more ability in the hands of the devs to focus the information flow.

[kazereal]

A lot has been said on this already but to gather some points a lot of the "grief" is that updates are released on six month periods which is a long time to wait? Or maybe I just misinterpreted..

 

Anyway, could it be considered that simpler, more obvious and critical bugs could be patched between those major releases? If we call the major releases "feature" releases and patches as "hotfix" releases would that be clearer?

 

Of course there are very complex interactions and fixing/changing might have to wait until "feature" release to be fixed and properly tested not to cause regressions or to break something else.

 

From what was said in this thread I gather that there are already development and release branches in the source control/version control system at ED since there are coming/in progress versions in bug tracker already? That would imply "out-of-band" hotfix/patch for a critical issue might not be maintenance nightmare regarding source code?

 

And to repeat myself a bit: if the patch would need large changes or extensive testing it would have to wait for larger release for proper integration. Only those "game-breaking" obvious-to-fix patches would go through a "hotfix" release.

 

So how does that sound? In 1.2.8 this kind of approach seems to have started in the open beta version anyway.

 

This would achieve quicker fixes to most troublesome problems and community (customers) would get the feeling that their worries ARE being addressed?

[cichlidfan]

A lot has been said on this already but to gather some points a lot of the "grief" is that updates are released on six month periods ...

 

Where did you get the six month number from? I can't recall a sixth month gap between updates (at least since World was released).

[kazereal]

Where did you get the six month number from? I can't recall a sixth month gap between updates (at least since World was released).

 

My bad, sorry. Just what I recalled from last couple of releases.

It does seem like releases ARE getting farther apart than what they were though.

 

(Looking at release dates from here: http://www.digitalcombatsimulator.com/en/news/)

[ShuRugal]

well, the alternative is no better: around the time of 1.2.x, patches were coming so fast and furious that practically every day something was fixed and something else broken.

[Flagrum]

A lot has been said on this already but to gather some points a lot of the "grief" is that updates are released on six month periods which is a long time to wait? Or maybe I just misinterpreted..

 

Anyway, could it be considered that simpler, more obvious and critical bugs could be patched between those major releases? If we call the major releases "feature" releases and patches as "hotfix" releases would that be clearer?

 

Of course there are very complex interactions and fixing/changing might have to wait until "feature" release to be fixed and properly tested not to cause regressions or to break something else.

 

From what was said in this thread I gather that there are already development and release branches in the source control/version control system at ED since there are coming/in progress versions in bug tracker already? That would imply "out-of-band" hotfix/patch for a critical issue might not be maintenance nightmare regarding source code?

 

And to repeat myself a bit: if the patch would need large changes or extensive testing it would have to wait for larger release for proper integration. Only those "game-breaking" obvious-to-fix patches would go through a "hotfix" release.

 

So how does that sound? In 1.2.8 this kind of approach seems to have started in the open beta version anyway.

 

This would achieve quicker fixes to most troublesome problems and community (customers) would get the feeling that their worries ARE being addressed?

The 6 months might have come from me. But what I meant, was something different. I was not directly complaining that the time span between patches were too long. Instead I just suggested that fixing bugs that were introduced recently by the latest changes might be easier to fix than those that are older, like six months or more.

 

But if it just takes a certain amount of time to fix something - whatever the reasons are - then it takes that time.

 

Indirectly, yes, I was also complaining about the long time some fixes need. It just feels strange and is hard to understand to see a fix that corrects the shell ejection animation of the Ka-50 gun when it was reported many months ago, even together with a copy&paste solution. A fix that technically takes 5 minutes to be implemented (+- 2 hours for tests and other formalities maybe). But again, it is not so much about the time spans as such, it is more about understanding those. In this case it was clear: very low priority and I can accept that.

 

Just some pointers like "yes, we know about it, but no, we can't fix it right now" or "yes, this is important and we do our best to fix it asap" - that would be all I am really asking for.

[ajax]

Disclaimer: The following is just my opinion and I will only say it once then shut up.:)

 

...corrects the shell ejection animation of the Ka-50 gun

How can this bug even remotely compare in importance to fixing the problem where the Ka-50's Doppler or HUD systems cannot be repaired, a bug introduced in one of the Black Shark 2 updates--over two years ago?