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' _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
