[Development] Qt 5.5.0 header diff

[André Pönitz]

On Thu, Jun 11, 2015 at 08:55:24AM +0000, Knoll Lars wrote:
> >On Tuesday 09 June 2015 13:35:14 Oswald Buddenhagen wrote:
> >> On Tue, Jun 09, 2015 at 10:59:32AM +0000, Heikkinen Jani wrote:
> >> > Hi,
> >> > 
> >> > I tried to create error reports about the findings to be able to
> >> > follow-up the progress. Please create new one if something is missing.
> >> 
> >> the point was about the entirely new headers that were not in the diffs,
> >> i.e., entirely new apis. it's a quite different (and much bigger) task
> >> than ensuring compatibility with existing api revisions.
> >> 
> >> i can create a task, but it's not up to me to actually schedule it. lars
> >> (or multiple other maintainers) need to make that call.
> >
> >Any news on this? Will we set aside time to look at the new API in more
> >depth 
> >before publishing or will we rush out 5.5 with known and unknown API
> >issues?
> >
> >(yes, this question is meant to be suggestive :)
> 
> Well, afaik the new APIs have been reviewed, but maybe not as widely as we
> should have. But so far, I haven’t seen bigger issues apart from the one
> in Qt Network.
> 
> We’ll have to weight things against each other. Looking at that, I don’t
> believe delaying 5.5 is a good option as we’re getting extremely close to
> the summer break. I don’t think releasing in August is a better idea.
> 
> So I propose we’ll sit down here in the office today and tomorrow with a
> few people and go through the new APIs to be certain we didn’t miss any
> big issues. That’s the fastest way to get some certainty without too large
> risks to delay our release.

I'd guess that's pretty much the best solution for now.

Looking a bit further: (More or less) consistent API used to be one of
the core values of Qt. Right now introducing new API in a consistent
way seems to work mostly by inertia - *if* it works.

I also doubt it will work that way for eternity, as accidents (and worse,
intentional deviations from established patterns and conventions by some
approvers) accumulate.

To be blunt: Even though some of the existing patterns and conventions
*are* unfashionable in 2015, consistency is a value by itself. Any
*partial* "modernization" of the API destroys that consistency, and
therefore value. So even if "use pattern B instead of A" is
uncontroversial when considered isolated, it's not a given that using
B instead of A in new Qt API is a win. And that ignores the fact that
there's rarely an situaion of a B being *uniformly* better than an A.

Sitting down with a few people *is* a way to fix things up last minute,
but I'd feel more comfortable if something to the same effect was formal
part of the process.

I am not sure about the concrete abilities of gerrit infrastructure, but
having a bot adding a specific user (or two, or three) to any change
introducing new API does not seem completely impossible.

Regarding the specific user(s): Less is more. Looking back, the time
it worked best for me was when it was clear who the single person to
ask about names and conventions was. Yes, that's a bottleneck for the
process, but getting uniformity by simulated annealing is extremely
unlikely if the initial solution is immutable. Such as our API after
the first release.

Andre'