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

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: May 14, 2013, 22:14 UTC
Message-ID: <CAMP44s0Wd4VEc_mwr=xguVAnXvn+YVz24u8eS4Nyy0HCjwJ+dw@mail.gmail.com>
In-Reply-To: <7vzjvxfck2.fsf@alter.siamese.dyndns.org>

On Tue, May 14, 2013 at 4:59 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 8 quoted lines

> Felipe Contreras <felipe.contreras@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*.

Show 5 quoted lines

> "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.

Show 7 quoted lines

> 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.

Show 10 quoted lines

> 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.

Show 11 quoted lines

> 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