S-Pen support on LTS 2017.4?

Unity Engine
1

Samsung S-Pen support is broken on LTS 2017.4. It was fixed on all reported versions except LTS 2017.4. How can we nominate the backporting of this fix?

Edit: the issue states it is not reproducible on 2017.4.32 but broken in .33. I do not see anything in the release notes of 2017.4.33 that explains why it broke. There are some Linux input/touch changes but nothing obvious.

2

@davidlovegrove any idea?

3

Hi,

Sorry for any inconvenience caused by this issue. I’ll see if i can find out any information.

Thanks,

4

Hi,

A backport request has been opened for 17.4 and if all goes well it’ll be in 2017.4.37 on the 6th of February.

Thanks,

5

Thanks a lot david, especially with the ETA on the backport. Even if I know things might change it’s good to have a timeline.

6

@davidlovegrove we have a discussion internally raised by this (and a few other regressions) that affect a small percentage of users.

We use LTS because we need stability across our apps. I personally don’t think we are able to catch all those regressions if you are not. S-Pen are not our core target users so we can’t really test whether Unity breaks s-pen on a release for a platform.

It seems that the targeting of the fix towards 2017 LTS was missed. Yet the information that this regression existed was there in the issue tracking. From the issue page one could see a few things such as

  • the issue was affecting 2017.4.33
  • the issue was not affecting 2017.4.32 (so it was a regression)
  • the issue was fixed on other LTSes
  • the issue was not targeted to fix 2017.4 (so it was overlooked)
  • the issue was identified as FIXED but this is only a global status and I can’t use this to search for issues that are indeed not fixed for a particular version [1]

From that information one could have identified that the issue needed fixing for 2017 LTS. How wonder how often this happens?

So this raises a few questions to me:

  • how can we users precisely search for regressions affecting a particular version? I could use this to assess whether we want to upgrade to a particular LTS - the issue search is not precise enough ([1])

  • have you considered searching your own database to identify those issues that might have been overlooked for a particular version?

Thanks

7

Hi,

I don’t know the specifics for why this fix was not taken to LTS, i can try and find that out. All i will say is that 2017.4 is our most stable release and we therefore don’t take as many fixes to it as 2018.4 and 19.2. We want to reduce code churn there and it might have been felt that this bug wasn’t of sufficient severity.

how can we users precisely search for regressions affecting a particular version? I could use this to assess whether we want to upgrade to a particular LTS - the issue search is not precise enough ([1])

The data for which bugs found in new versions will get backported to older versions is internal at the moment. Just because something was found in say 19.2 doesn’t necessarily mean it will get fixed in an LTS. Each case is judged on a risk/reward basis with the constraints on older branches being tighter. Short of exposing our bug database to users (i don’t know if this is a good or bad idea) i’m not sure there is a solution to this.

have you considered searching your own database to identify those issues that might have been overlooked for a particular version?

Every case that comes in is triaged by our QA and tested against older versions. We also have a triage process for backports, to see if they’re viable. Quite often they’re not backportable as the codebase for an older version is signficantly different and therefore might render the backport impossible. Alternatively the case might not be deemed severe enough or too risky. Change code has a chance of introducing more bugs and it is something we don’t want to do on old versions unless we have to.

We take our customers opinions very seriously, which is why in this case we’ve looked at it again.

I hope I’ve addressed your concerns.

Thanks,

David