On Tuesday 20 January 2015 18:52:38 Dieter, William R wrote: > So, in return for linear history, the maintainer(s) now have to click > "Submit" in the right order on dependent changes. If they do not, the > changes will be submitted in the wrong order, the build will break, and a > sequence of invalid commits will be forever in the project's history. > > If linear history is important "Fast Forward Only" seems like it would be > safer. Not having used it, maybe I am missing something...
Hi Bill I apologise for getting this with sysadmins without talking on the ML first. I thought it was uncontroversial, since that's what I've seen several projects use... Can I suggest we trial it out for a period of time? If it introduces problems, we'll go back. There was no guarantee that the build wouldn't break with the "merge if necessary" strategy. The result of the merge, even without conflicts, can be wrong, due to the other changes that got accepted between the build results being posted and the actual submission. I'm not sure Fast Forward Only is an option for us. There are way too many changes happening in the master branch, so by the time you get the +2, something else has been approved and your change is no longer a fast-forward. I don't know if Gerrit retains your +2s if you click the Rebase button. At the very least, that should trigger a build again and testing. In my experience, the majority of the changes (> 50%) is one commit alone, so the cherry-pick solution is equivalent to what we have right now with merge- if-necessary. Of the remaining, the majority is again of two or three changes, so you're not likely to get the order wrong. And even if you do, there's also a good chance that Gerrit will reject your order of submission due to path conflicts. And even if you get it through in the "wrong" order, you may not break the build, so it might not be wrong after all. In any case, the only way to guarantee that it works is to do a test *after* you submit and reject the submission if the build breaks. Often that also requires batching submissions, since one commit may be incomplete. That's what the Qt Project does. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
