Concerning «the forgotten bugs»

[Capostrophic]

This is a list of tracked bugs which were never given a target version.

Although it was discussed a while ago, I feel the need to reestablish the topic: these "minor" issues tend to never be noticed by both the community (wild duplicate issues may appear) and the "worker bees" of OpenMW, and some of them are quite observable, like the bug #3536.

Something has to be done about it — at least, merely targetting the issues for openmw-future "version".

The same goes for the missing features. Another example: the shader water is somewhat inferior in some ways to original ATI pixel shader one, according to the feature #3537, and if we want OpenMW to be "a 100% Morrowind.exe replacement" for version 1.0, this needs to be addressed too.

What do you think?

Edit: the parser wrecked the links, ugh. Made a workaround: used an URL shortener.

[Atahualpa]

This is a list of tracked bugs which were never given a target version.

Although it was discussed a while ago, I feel the need to reestablish the topic: these "minor" issues tend to never be noticed by both the community (wild duplicate issues may appear) and the "worker bees" of OpenMW, and some of them are quite observable, like the bug #3536.

Something has to be done about it — at least, merely targetting the issues for openmw-future "version".

The same goes for the missing features. [...]

+1

Would it be possible to force a target version by setting a default entry -- either "openmw-future" (which would ignore OpenMW-CS features) or something like "uncategorised issues"?

Another example: the shader water is somewhat inferior in some ways to original ATI pixel shader one, according to the feature #3537, and if we want OpenMW to be "a 100% Morrowind.exe replacement" for version 1.0, this needs to be addressed too.

I noticed this issue too. It should definitely be addressed before version 1.0.

[CMAugust]

Hey whaddaya know, I submitted those

It definitely appears true that issues which aren't promptly given a target version are promptly forgotten. It's tempting to just assign a target version when writing the reports, which risks needing correction but at least would remain on the radar until then.

(despite this, I'm still amazed how many of my bug reports have been fixed; great job devs!)

[hlamas]

I remember submitting this some time ago, with a video attached:

https://bugs.openmw.org/issues/3563

It was related to the collision engine. Not sure if this is the right place to bump it, but it applies to all actor collision, and is still present in 0.41 . Watching it again, I would call it a type of "snapping" that can take place when actors collide, allowing the player to move NPCs.

[AnyOldName3]

That probably relies on Bullet, and currently, no active developer actually knows how Bullet works. There's a new guy who might be able to figure it out, but we can't expect too much from him, as for all we know, that code's a total mess and no-one will want to tough it ever.

[Jyby]

Hey whaddaya know, I submitted those

It definitely appears true that issues which aren't promptly given a target version are promptly forgotten. It's tempting to just assign a target version when writing the reports, which risks needing correction but at least would remain on the radar until then.

(despite this, I'm still amazed how many of my bug reports have been fixed; great job devs!)

Would it be harmful to give all bugs without a target version, 0.42.0? Ideally we could give new reports a default target version, i.e. the next release version.

[MiroslavR]

Would it be harmful to give all bugs without a target version, 0.42.0? Ideally we could give new reports a default target version, i.e. the next release version.

Yes, it would. Unless you confirm all of them and make sure they're not duplicates.

[Jyby]

Would it be harmful to give all bugs without a target version, 0.42.0? Ideally we could give new reports a default target version, i.e. the next release version.

Yes, it would. Unless you confirm all of them and make sure they're not duplicates.

Well bugs shouldn't be worked on unless they are confirmed, so marking them as 0.42.0 doesn't indicate they are ready to be fixed. I do see a problem where our change log would become hard to create, but then again the bugs in the change log are marked closed. In terms of meeting all the required items for a specific release I see why it would be bad.

What specific problem did you think of? Aside from future post 1.0 or editor related bugs.