On Friday 22 May 2015 07:54:50 Lankswert, Patrick wrote: > Thiago, > > If we do not squash before merging two active branches with conflicts, the > load is higher on the maintainers as a result of merge conflicts AND I must > insist that every commit be reviewed on every branch so that pulling > against any given commit id on the resulting release branch will provide a > reasonably sane code base. I understand that mistakes happen and bug make > it past review, but the going in proposition should be the we believe that > every commit is thought good and complete. > > I am open to changing the stance, but as a community we should make claims > and promises that the community can rely on.
Hi Pat I understand where you're coming from. Indeed, we usually want to review every single commit to ensure that they are correct. This is required when each commit is individually submitted to Gerrit, since they will be rebased/cherry- picked onto the master branch. However, this will not work for a long-term branch where multiple parties are working to develop a feature. Those long-term branches cannot do a rebase/cherry-pick, so they need to do merging or squashing. If I had to choose, I'd choose merging, even if we import commits that aren't properly reviewed or are even broken (not passing all tests). The end state is more important. The remaining question is how to choose between the two. I'd say that every single feature, no exceptions, should start being developed as the first option. Developers should rebase their branch often and push the commits (however many) to Gerrit, reacting to feedback and rewriting commits as needed. We should change to the second process if and only if there are characteristics that require it, such as multiple people collaborating or too many commits to keep rebasing, etc. In order to do that, the target maintainer needs to give an explicit approval. Would this process work? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
