[Development] Deprecation warnings are enabled

[bradley.hughes at nokia.com]

On Apr 30, 2012, at 7:19 PM, ext Thiago Macieira wrote:

> On segunda-feira, 30 de abril de 2012 16.58.08, bradley.hughes at nokia.com 
> wrote:
>> Seriously? What about my comment (plea) to revert the change that enabled
>> these warnings? As I mentioned before (and others in my team), these
>> warnings are hurting more than helping, and our time is much better spent
>> working on the desktop platform plugins than fixing warnings.
>> 
>> Please, I hope you will reconsider, there's much more important things to be
>> done.
> 
> I'm not against postponing them. Really, if you need more time, then it's 
> completely understandable and we should give you more time. I could certainly 
> use more time because I have two high-importance tasks to do that need to be 
> done in 5.0, plus maybe looking into QList.

More time is something that we would all like, but it's not always realistic. My argument here is about how we effectively use our time. Given the average turn around time of CI, and the complexity that arises from maintaining multiple unrelated changes on-top of master, I think we're doing harming ourselves more than helping.

When faced with two options, 1) fix deprecated warnings or 2) continue work to restore Qt 4 behavior in the platform plugins, I'm going to say we should be doing 2) and not do 1) at all (since there will be disruptions and distractions because of it).

> I'm acting on the belief that this is a beta-blocker task. If it is and you 
> need more time, then we may have to delay the beta too. Or, I am mistaken and 
> it is not a beta-blocker.

I've always been under the impression that the desktop platform plugins won't block any release. The state they are in at release time is the state they are in… we will be constantly fixing and implementing both up to and and well beyond the 5.0 release. Postponing isn't feasible because it's impossible to say how much time is left.

> I've already spent almost a week getting the QRegExp const change done because 
> it seemed like the right thing to do and required for the beta. Given the 
> choice, I wouldn't have spent any time on it. And I have a couple more tasks 
> assigned to me that seem to be required for the beta, but I'll happily leave 
> them for later instead.

Likewise, I spent most of the day getting Qt Creator compiling again after the QRegExp change (instead of working on the QPA API changes that we need). Granted, not a week like you spent, but the point here is the interruption. 

Like you, I wouldn't have done the QRegExp changes given a choice, but when the stuff lands in master, we have no choice: drop what you were doing and fix the breakages instead.

Summing up, this is what I'm afraid of: we're going to end up wasting a lot of time fixing things that are in the way, not because they are important right now (note that I'm not saying they are unimportant altogether, just that there other things trump them).

--
Bradley T. Hughes
bradley.hughes at nokia.com