FDEV I can't believe you re-introduced another bug from the beta, AGAIN!

Cmdr Esteban

Cmdr Esteban
I want to post my unanswered questions from another thread here, regarding the reintroducing of bugs, and hope someone can answer them:

Cmdr Esteban said:
As a layman unfamiliar with programming/coding, I can never understand how old bugs return in new updates. I vaguely recall someone once saying that in large design teams some individual coders somehow end up using older code for a specific game function in an update, and that's how old bugs creep back in. I don't know if that's true, but if it is, aren't code versions marked with a date or some other label denoting their currency? How could a competent person make that simple error? Would it not be a simple matter just to update the most recent version? I genuinely don't understand these matters and wonder if someone savvy could explain. Thanks.
Click to expand...
Cheers
 

DragonIV

DragonIV
Cmdr Esteban said:
I want to post my unanswered questions from another thread here, regarding the reintroducing of bugs, and hope someone can answer them:
Cheers
Click to expand...

I have tried to reply to you a few times, but the sad fact of it is software configuration management is very, very tough and I'm having a heck of a time to simplify it. :) In effect, with multiple dev teams running various levels of fixes/new development, they may not all have started at the same time and perhaps didn't base their fix on that same release of code. Before going live, if they did not make their fix on the current version of the code, they need to identify the differences and bring their version of code up to date with release.

That process can get devilishly complex in a huge project with many resources, and if not done right, old code that had bugs fixed by another team in a more recent release could get those bugs pushed back into prod by this new fix if their fix was not synched to production correctly (effectively, not including the fixes made by this other team).
 

Cmdr Esteban

Cmdr Esteban
dragoniv said:
I have tried to reply to you a few times, but the sad fact of it is software configuration management is very, very tough and I'm having a heck of a time to simplify it. :) In effect, with multiple dev teams running various levels of fixes/new development, they may not all have started at the same time and perhaps didn't base their fix on that same release of code. Before going live, if they did not make their fix on the current version of the code, they need to identify the differences and bring their version of code up to date with release.

That process can get devilishly complex in a huge project with many resources, and if not done right, old code that had bugs fixed by another team in a more recent release could get those bugs pushed back into prod by this new fix if their fix was not synched to production correctly (effectively, not including the fixes made by this other team).
Click to expand...
That helps a great deal, thanks. Seems like a mismanagement issue then, if I read that right (as in, not ensuring all team members are on the same page, so to speak). Really appreciate your explanation. Cheers.
 

VR SenseiMatty

VR SenseiMatty
dragoniv said:
I have tried to reply to you a few times, but the sad fact of it is software configuration management is very, very tough and I'm having a heck of a time to simplify it. :) In effect, with multiple dev teams running various levels of fixes/new development, they may not all have started at the same time and perhaps didn't base their fix on that same release of code. Before going live, if they did not make their fix on the current version of the code, they need to identify the differences and bring their version of code up to date with release.

That process can get devilishly complex in a huge project with many resources, and if not done right, old code that had bugs fixed by another team in a more recent release could get those bugs pushed back into prod by this new fix if their fix was not synched to production correctly (effectively, not including the fixes made by this other team).
Click to expand...

Designing a real spaceship is easier then... I'm a mechanical designer, when I release a new version of my drawings, even if previously done by other people, it's very unlikely that I re-introduce a previous version of an installation.
 

throbclip

T
Cmdr Esteban said:
I want to post my unanswered questions from another thread here, regarding the reintroducing of bugs, and hope someone can answer them:


Cheers
Click to expand...

Version control - Wikipedia

en.wikipedia.org en.wikipedia.org

Is the subject and yes it is complex with various branches: live system, testing, development etc that are updated at different rates for different purposes. Then there is

Regression testing - Wikipedia

en.wikipedia.org en.wikipedia.org

Where you try to check that you haven't reintroduced problems. There are always multiple potential points of faliure along the development pipeline and these practices are there to minimise them but if they are short-circuited, usually due to cost, bugs will often return.
 

DragonIV

DragonIV
SenseiMatty said:
Designing a real spaceship is easier then... I'm a mechanical designer, when I release a new version of my drawings, even if previously done by other people, it's very unlikely that I re-introduce a previous version of an installation.
Click to expand...

I believe it is. I worked as a engineer on in-core detectors for nuclear plants prior to going into software development, and, well, that was also hard, but not to the insane levels of configuration control. Thankfully, I don't do that work much any more.
 

Cmdr Esteban

Cmdr Esteban
throbclip said:

Version control - Wikipedia

en.wikipedia.org en.wikipedia.org

Is the subject and yes it is complex with various branches: live system, testing, development etc that are updated at different rates for different purposes. Then there is

Regression testing - Wikipedia

en.wikipedia.org en.wikipedia.org

Where you try to check that you haven't reintroduced problems. There are always multiple potential points of faliure along the development pipeline and these practices are there to minimise them but if they are short-circuited, usually due to cost, bugs will often return.
Click to expand...

Very comprehensive explanation - thanks mate. :)
 

dreampage

dreampage
This bug has never occurred to me before (and I finished the whole Distant Worlds 2 expedition!) but since the April Update Patch 1 it's constant. Extremely annoying. ☹ Confirmed it in the Issue Tracker, too.
 

-VR- Max Factor

-VR- Max Factor
SenseiMatty said:
I'm talking about the zoom out in the FSS. Now it always zoom back centered on the main planet and not on the last moon making the FSS experience very confusing.
This was already spotted and corrected during the beta and re-introduced with the last patch :mad:😭😤🤬
I want to cry... 😭😢😭😢😭😩

Everyone, please give your contribution here:
Issue Tracker Bug Report
Click to expand...
I'm assuming its a different bug that looks the same as the last version. There are many issues with the FSS at the moment since the last update and this one isn't the worst.
 

Kenneth McGrew

Kenneth McGrew
SenseiMatty said:
I'm talking about the zoom out in the FSS. Now it always zoom back centered on the main planet and not on the last moon making the FSS experience very confusing.
This was already spotted and corrected during the beta and re-introduced with the last patch :mad:😭😤🤬
I want to cry... 😭😢😭😢😭😩

Everyone, please give your contribution here:
Issue Tracker Bug Report
Click to expand...

im wasting my votes on grammatical errors in the stations text, these are game breaking, voting for real bugs... pffffttt


wait actually im not even using that pile of crap they call an issue tracker.
 

Ian Doncaster

Ian Doncaster
dragoniv said:
I have tried to reply to you a few times, but the sad fact of it is software configuration management is very, very tough and I'm having a heck of a time to simplify it. :) In effect, with multiple dev teams running various levels of fixes/new development, they may not all have started at the same time and perhaps didn't base their fix on that same release of code. Before going live, if they did not make their fix on the current version of the code, they need to identify the differences and bring their version of code up to date with release.

That process can get devilishly complex in a huge project with many resources, and if not done right, old code that had bugs fixed by another team in a more recent release could get those bugs pushed back into prod by this new fix if their fix was not synched to production correctly (effectively, not including the fixes made by this other team).
Click to expand...
You can also in a complex project have the same apparent bug have multiple causes, so while the symptoms are the same they're not caused by the same thing in the code.

For a toy example:
$FSSZoomOutLocation = function() + otherFunction();
A bug in either function (or anything called by those functions) results in the zoom out location being wrong.

Worse, it's the sort of thing which good version control discipline doesn't really fix [1] - the branch changing function() will merge perfectly cleanly with the branch defining $FSSZoomOutLocation as depending on it. The people who changed function() checked the cases that were using it on their branch, the people using it for FSSZoomOutLocation would have been fine with the old definition and checked it on their branch, it's only applying both at once that's the problem.


You can also have changes where a bug is hidden by another bug. For example (again, a toy one)
if (playerIsWanted()) {
$buggybehaviour = true;
} else {
$buggybehaviour = false;
}
Easy - the bug shows up if the player is wanted.

But what if playerIsWanted() has a bug which means it always returns false? Then the bug in this bit of code never actually happens, because it never gets to that branch. When the bug in playerIsWanted() is fixed, this bug then shows up, despite this code file not having been touched for years.


[1] In these toy examples a good unit test suite would catch them. But once you get into interactions with shared data state, persistent variables, etc. getting the test suite to that standard becomes very tricky, because all the components work fine, it's the assumptions made in connecting them which are wrong, and feature tests or automated acceptance tests are much harder to write. Especially in something like Elite Dangerous where you have the client talking to multiple servers.
 
You must log in or register to reply here.
Back
Top Bottom