On quinta-feira, 21 de março de 2013 16.12.51, Qi Liang wrote: > > When there's a conflict the merger does not know how to resolve, the > > merger > > asks for help. Choosing unconditionally one side is a bad idea. > > I don't think the merger has enough time to do that. And under open > governance & gerrit, there is a risk for merge, maybe some incoming commits > will break the merge.
The merger must do that. Always ask for help. If no help comes in reasonable time, then and only then should the merger make a decision based on available information. And then post to the mailing list. > > It's not the first dev-stable merge. The direction does not matter. This > > merge is no different than the previous ones. > > Had we done any merge from Qt 4.x to 4.x-1 or similar before? Before, we > think stable as 5.0 and dev as 5.1, then we prefer bug fixes in stable, > features in dev. We've always done merges between versions N and N+1. If you declare M = N + 1, then we did merges between M - 1 and M. Any way you do this, we've done this before. The direction does not matter. > But now, I don't think stable and dev are much different in current release > cycle, just a time difference, all changes in dev will be in stable after > this "BIG" merge procedure, just means the users of stable branch will get > the fixes in a short time or a few months later. The only difference this time is that we updated the stable (previous version) branch. That's *really* the only difference. Everything else is the same as it has always been ever since we introduced Git usage for Qt, back in 2008. (I'm sure there was a blog, with a picture of Lars and Simon talking to the sysadmins, turning the Git repository live for the first time, but I can't find it) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
