[PATCH v2 1/1] Update Subsurface with the updated QSysInfo from Qt 5.4

[Dirk Hohndel]

On Sun, Aug 17, 2014 at 11:15:07PM -0700, Thiago Macieira wrote:
> On Sunday 17 August 2014 23:36:32 Dirk Hohndel wrote:
> > CHRIST. Please. I am NOT INTERESTED in changing what is sent in the survey
> > or as the User Agent string.
> > 
> > Now the survey changed to something like this:
> > 
> > survey?ssrfVers=4.2-55-gc935ffcca386&kernelType=linux&kernelVersion=3.15.8-2
> > 00.fc20.x86_64&productType=fedora&productVersion=20&buildCpuArchitecture=x86
> > _64&currentCpuArchitecture=x86_64&uiLang=en-US&suggestion=&recreational=1&te
> > ch=1&planning=1&download=1&divecomputer=0&manual=0&companion=1"
> > 
> > instead of
> > 
> > survey?ssrfVers=4.2.0&prettyOsName=OS%20X%20Mavericks%20(10.9)&appCpuArch=x8
> > 6_64&uiLang=en&recreational=0&tech=1&planning=1&download=1&divecomputer=1&ma
> > nual=0&companion=0&suggestion=
> > 
> > I don't give one yota which kernelVersion the user runs. I quite
> > intentionally want to send the "prettyOSVersion" I don't want to change the
> > "appCpuArch=" parameter to "buildCpuArchitecture=" etc.
> 
> The problem is that the functions in QSysInfo changed for Qt 5.4. For 
> appCpuArch I could leave the build CPU arch, but the pretty name will not 
> contain the same information. 
> 
> So I can change to send the same fields, but the content will change slightly.

I am OK with slight changes to the content of the fields (I'm curious as
to what and why), but I don't see why that would make us pick different
fields. And I want to make sure that such changes are explained in the
commit message.

I definitely want the same fields and unless there is strong reason I want
the same field names.

To me this is an API. Yes, I'm the only consumer so I CAN change it. But I
hate the idea of patches that randomly change things without explanation
what and why.

When I changed the User Agent before the 4.2 release it was clearly
explained why I felt the new one was better. It was much more compact,
easier to parse, and better structured.

There is a really idiotic bug in the name of the arguments for the survey
check boxes (downloading from the divecomputer is called "download", but
importing from other sources is called "divecomputer" - what the hell is
that???) and I never noticed until I started running analysis against the
data. Yes, I will change that eventually and will change the backend to
deal with both versions. But again, this will be explained and I will
track it on the backend.

If the prettyOSVersion changed then tell me why and how and then we can
look at that change and I can figure out what I do with it on the backend.

But don't just send me something that changes the API and doesn't even
mention it in the commit message.

/D