On Tue, May 14, 2013 at 4:59 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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. This issue has *always* been there, it's not a regression. > Are we giving the users enough time to discover and complain issues > that these 10 patches may introduce before the final release? Yes, because the time needed is *zero*. > "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. There was no original patches that introduced this regression, because it's not a regression. When I say these are trivially correct, I mean it; the regressions you talk about were on patches that were marked as *not* trivially correct, and potentially dangerous. > 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. Define "ready". It's probably more "ready" than any other bridge tool out there. > In other words, it still seems to be in "something is better than > nothing, newer is better than older" stage before stabilization. remote-hg is already stable, this patch has nothing to do with stabilization, neither do any of the 47 patches I sent to the list. > 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. It's not adding any configuration; remote-hg.track-branches is already present, even in v1.8.2. > 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. Indeed, they are exactly the same as the first 10 patches of the 47-patch series. I think this makes sense. -- Felipe Contreras -- 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