Re: [PATCH v3 08/10] remote-hg: update bookmarks when pulling

On Tue, May 14, 2013 at 4:59 PM, Junio C Hamano [off-list ref] wrote:

Felipe Contreras [off-list ref] writes:

quoted

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:

quoted

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