On Tue, May 14, 2013 at 4:59 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Felipe Contreras <felipe.contre...@gmail.com> 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*.
> 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
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
I think this makes sense.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html