761781 - Feature Request: Input.mozilla should get BuildIDs from users

Status: RESOLVED WONTFIX

(Input Graveyard :: Submission, defect, P3)

Description

[Lukas Blakk [:lsblakk] use ?needinfo]

We're looking to have this as part of a more rapid beta release cadence (see https://wiki.mozilla.org/Release_Management/Rapid_Betas) where betas will be automatically built and made available to users every day there are code changes.  With this more frequent updating we will likely see a bit of spread over a few days of builds so getting the buildID from users would be quite helpful in regression range finding as well as QA.

Comment 1

[Matt Grimes [:Matt_G]]

This might be easier once we get the about:support api.

Comment 2

[Will Kahn-Greene [:willkg] ET needinfo? me]

We've got access to remote-troubleshooting (aka about:support) now.

Cheng: Are there build ids in the remote-troubleshooting data? Are we don with this bug?

Comment 3

[[:Cww]]

I'm now super confused because I distinctly remember writing a response to this last week.

The answer is yes, it's in the remote-troubleshooting data so we COULD get it out.

However, we're also getting more requests to do things like sort feedback by beta number (which we have to look up via build ID) so it'd be really helpful if this were a separate thing that we could pull from the DB directly.

That said, the priority isn't as high (since we can technically script pulling something on demand)

Comment 4

[Will Kahn-Greene [:willkg] ET needinfo? me]

We could make a separate column for that and populate it when we get incoming feedback. That's probably a couple of days of work, I think.

Is that really helpful or just vaguely helpful? Also, do you want to backfill that column where we can?

Comment 5

[Will Kahn-Greene [:willkg] ET needinfo? me]

Oops--tagging Cww with a needsinfo to answer questions in comment #4.

Comment 6

[[:Cww]]

Vaguely helpful for now, but it could be really helpful on a moment's notice (like when we break stuff in beta). Backfill if we can for sure. 

If we're already collecting it and backfill is simple, let's not worry about this for now.

Comment 7

[Will Kahn-Greene [:willkg] ET needinfo? me]

So next steps:

1. check to see if we're collecting it and if so, where in the remote-troubleshooting data it is

2. create a column in the feedback_response table (aka Response model) for the build id

3. tweak the feedback handling code to check the remote-troubleshooting data for the build id and put it in the Response record if we have one

4. write a data migration to backfill build ids


Tossing in the queue.

Comment 8

[Will Kahn-Greene [:willkg] ET needinfo? me]

I see a thing that purports to be a buildID in the remote troubleshooting data:

 u'application':
     u'buildID': u'20150513174244'

Pretty sure that's what we want. Pretty sure that satisfies item 1 and makes this possible with the data we've got now.

If we do a data migration to backfill, we'll only fill in build ids for feedback responses where the user opted into collecting remote troubleshooting info. That's a pretty key note since some/many users don't opt in.

When we make these changes, we want to make sure to capture the build id regardless of whether the user opted into collecting remote troubleshooting info. We want to also make sure we're not capturing the rest of remote troubleshooting info if the user didn't opt into collecting remote troubleshooting info.

I'm going to bump this up to P3 so it's higher in the queue.

Comment 9

[Will Kahn-Greene [:willkg] ET needinfo? me]

It's a new quarter!

Comment 10

[Osmose [:osmose, :mkelly]]

The Input service has been decommissioned (see bug 1315316) and has been replaced by a redirect to an external vendor (SurveyGizmo). I'm bulk WONTFIXing Input bugs that do not appear to be relevant anymore.