On Tue, May 14, 2013 at 5:25 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Felipe Contreras <felipe.contre...@gmail.com> writes:
>> 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
>>>> 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.
> Then why are you rushing it? -rc is a "regression-fix-only" period.
I'm not rushing this patch, I'm rushing the regression fix. I added
the cleanup patches because they help the fix, and I added this patch
because it's obviously good.
>> Define "ready". It's probably more "ready" than any other bridge
>> tool out there.
> Anything that needs "oh, we need to push these ten patches to avoid
> regressions at the last minute" is not mature enough to be relied
> upon by end users for everyday use. That is what I meant.
Only a single patch is needed to fix the regression and I sent that
patch standalone in v2 of this series, but you didn't pick it, so I
sent the cleanups as well.
> But now you are saying these are not regression fixes, in which case
> they have to wait because the users have known about the limitations
> that existed for a long time and learned to live with them. That is
> a sign of mature (not "not ready") software.
No, they don't have to wait. And we don't have to mindlessly apply
guidelines as dogma.
The reason for the "only regression" period is to avoid more
regressions. If you show me how any of the fixes I sent in this series
could potentially cause a regression, I would agree with you, even if
remote, the possibility would be there, therefore the patch wouldn't
be material for 1.8.3.
But the fact of the matter is that the possibility is not there, we
are not decreasing the possibility of regressions, we are simply
removing a feature users could enjoy for no gain at all.
> You cannot be both. Which is it?
I marked the patch that fix a regression as such, I marked the patches
that are obvious fixes with no possibility of regressions as such, and
I marked the trivial cleanups with no possibility of regressions as
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