> the thing is that 4.7 is closed as far as the qt project is concerned. > we have cemented this decision (made by qt nokia RM) by creating facts - > fixes are not being applied to 4.7 first, and given the strong > forward-merge-only preference, this cannot be revised without creating > ugliness. > Still, the patches are there, and they improve Qt. As I see it, there are different set of fixes:
- Backports from Qt 4.8: They can be applied after review. I don't see any problems there - Fixes that only apply to Qt 4.7: Same here, they can be applied just like that - Fixes that have only been applies to the 4.7 release for no good reason: I haven't checked if those exists, and they would not make anyone's live easier (including Digia's). They might have happened because they also exist in Qt 4.8 first (in a Digia-internal repo) and see the light of the public for the first time in the 4.7 release. in that case, it's Digia's duty (and self-interest), to apply the patch against both branches in Gerrit). > fwiw, we'll probably need to re-define what the criteria for bugfix > branches are if we don't want digia to have secondary branches all the > time. "P0 and P1 bugs only" is simply no sane submit policy as far as > anyone actually *using* our stuff is concerned. our pre-existing > downstreams (i.e., linux distributors, but also maemo and symbian) have > shown this rather conclusively. IIRC, "only bugfixes that are safe to apply" was the policy, not "only P0 and P1". There can be perfectly annoying P3's that can be easy to fix. In an ideal world, regression tests would be the benchmark, but that doesn't work. Anyway, patches that are dangerous or even add features can still be in Qt git. If Digia wants to provide them publicly, they should be in a special branch (either one branch per feature or in one vendor-branch). The same goes for other contributing individuals/companies. The Kernel shows rather well that this can help more than it hurts. Disk space is cheap, and we have a clear indication of what's the authoritative upstream branch. Cheers, Daniel _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
