Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > Without this fix, the user would never ever see new bookmarks, only the ones > that (s)he initially cloned. Now, think again and realize how long it took you (the original author) to discover issues and come up with these fixes and explanation since the series was merged before -rc0. Are we giving the users enough time to discover and complain issues that these 10 patches may introduce before the final release? "You can see these patches are so trivially correct" is not a valid argument. The original patches would also have been looked correct when they were sent to the list. Things take time and actual use by the users to mature. Having said that, the impression I am getting is that whatever we pushed out in 1.8.2 and 1.8.3-rc0 was far from ready for real use, and with your explanations (by the way, I found that many of them deserve to be in the log message), the end result of applying these patches, up to 8/10, will still not be as it is very likely that you and users will discover issues at a similar rate, but at least it will be much closer to be ready than they currently are. In other words, it still seems to be in "something is better than nothing, newer is better than older" stage before stabilization. And that is to be expected for a contrib/ material; nothing for us to be ashamed of. So I changed my mind. As long as it is clearly marked as "still experimental, possibly with rough edges", I think it is better to ship 1.8.3 with these 8 patches than without. I am unhappy with 3/10, though. It is spreading existing mistake by adding another configuration variable with dash in its name, which goes against the recommended practice, and making it more cumbersome to eventually fix them, because we would need to break end user's configuration. Things like 1/10 and 2/10 that can be characterized as: > This is a trivial cleanup, cannot cause regressions. may probably be a good clean-up to build the next development cycle on top, but are not at all urgent for it to deserve to be included in the upcoming release. But it seems that 3-8 textually depend on at least 2, so I'll queue the first eight for 1.8.3 and exclude the rest for now. If these are identical to the early part of the 47-patch series (I didn't check; they are for the next cycle), it would make the next cycle shorter by 8 patches. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html