On Fri, Apr 26, 2013 at 5:23 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Junio C Hamano <gits...@pobox.com> writes:
>> Felipe Contreras <felipe.contre...@gmail.com> writes:
>>> Updated the commit messages, so we say Bazaar instead of Mercurial, and 
>>> stuff.
>>> Here's a bunch of cleanups mostly to synchronize remote-bzr and remote-hg.
>> Thanks.  Will queue on 'pu' without looking.
> Actually, I was going to merge fc/remote-hg and fc/remote-bzr down
> to master anyway, so I'll just apply them directly on 'master'.
> By the way, I personally do not think the quality of the changes to
> remote-bzr matters all that much at this point in its history.  It's
> not like millions of people use it heavily from the v1.8.2 release.
> A huge patch series from its original author and nobody else, either
> reviewed or unreviwed, would not hurt them more than the one in the
> v1.8.2 version anyway. And it is also not like bzr-to-git population
> will grow significantly in the future to require us to pile a lot of
> features on remote-bzr that makes the maintenance burden of it
> becomes an issue.
> Am I underestimating the pain of potentially breaking existing
> remote-bzr userbase?

No, I think it's reasonable. 1.8.2 was better because 1.8.1 didn't ave
any support whatsoever, and 1.8.3 will be better, because 1.8.2 was
barely usable for any real-world project. Will there be any
regressions? I doubt it, and if there are, it's unlikely that they
would be found in the review process, in 'pu', or in 'next', specially
since very few people actually use remote-bzr, in part because it
wasn't very useful, and in part because few people use bzr in the
first place.

Of course, I would prefer if people reviewed the patches for the
massive changes, the _important_ patches, and I would gladly explain
the reasoning and update the commit messages if needed. But nobody is
volunteering to review that. The only exception was for a few
irrelevant patches that could be easily dropped.

remote-hg is a different story, and so I'm being more careful with the
changes there, and I actually think the current patches are more than
enough for 1.8.3, they should be tested in an actual release, and the
rest would have to wait. For the rest, I'm still juggling in which
order I should send them, and I want to send first the ones that
should maximize the benefits for the users, with minimum possibility
of breakage, but even then I wouldn't be confident with those landing
in 1.8.3, so 1.8.4 it is.


Felipe Contreras
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

Reply via email to