Junio C Hamano [off-list ref] writes:
Felipe Contreras [off-list ref] writes:
quoted
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?
On Fri, Apr 26, 2013 at 5:23 PM, Junio C Hamano [off-list ref] wrote:
Junio C Hamano [off-list ref] writes:
quoted
Felipe Contreras [off-list ref] writes:
quoted
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.
Cheers.
--
Felipe Contreras