SZEDER Gábor <szeder.dev@xxxxxxxxx> writes: >> If you feel uncomfortable and want these to cook longer, please tell >> me so. > > Well, it was mainly my surprise that a 20+ patch series arriving so > late that it gets queued on top of -rc0 would still make it into the > release. It all depends on what area the changes are about ;-) Not meaning to make light of your contribution, but if the upcoming version of Git shipped with a slightly broken completion, and the breakage is severe enough, the only thing we need to do is to do a maintenance release that reverts a single script. Distro packagers may do that for us. While waiting, the user can choose not to load the completion and can keep using Git just fine. A broken "mergetool" would be similar in that a workaround to inspect "git diff" is available. If we break "pull" or "commit" on the other hand, the necessary workaround would be a lot more involved. Some changes in low-impact areas can wait without reducing the end-user value of the new release, but if the risk of regression is small, I favour merging them, rather than postponing them for one cycle, if only to reduce the number of patches that I need to hold onto. Patches to clarify existing documentation fall into this category. My perception of "risk of regression" obviously is affected by the size of the series, and 20+ is certainly on the larger side. But other things also come into the picture. Patches from an author who knows the area the patches touch very well and with track record of not causing embarrassing regressions, would make me feel safer than patches from others, for example.