Re: [PATCH v2 00/18] remote-bzr: massive changes

> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> After being contacted by the emacs developers and others who are stuck with
>> Bazaar, which at this point seems to be utterly abandoned, I realized the
>> current implementation is too crude.
>> ...
>> That is of course, if pushing actually worked (which in many cases doesn't).
>>
>> In short, our support for real-world projects suck.
>>
>> These patches fix all the issues I encountrered.
>> ...
>> Finally, after all these changes I was finally able to clone the whole emacs
>> repository, all 130685 commits, and 56 branches without running out of memory
>> in my modest laptop.
>
> Yay ;-)
>
> I assume that the trees at a handful of key points (e.g. releases)
> were verified to be identical with the original history and the
> conversion result.

>> I'll ask the emacs developers to give them a try, and let's see
>> how it goes.
>
> Yeah, that's the least we can do for both existing and future users.
>
> Generally speaking, post -rc0 is too late for "if no issues are
> found", simply because no existing user has enough time to find
> corner case regressions in her work using the new software (I do
> not expect a trivial bug that can be uncovered in a few weeks of use
> would remain in a version that has successfully converted the Emacs
> history; but real world users always have different needs than what
> we anticipate).
>
> I however am finding myself moderately receptive to this series.
> That is primarily because this series touches only two files that
> are totally isolated from the rest of the system.  Even if they did
> not work at all, there is no risk for the remainder of Git.  Nobody
> other than existing users of remote-bzr will even notice if we
> merged this by the final.
>
> For existing users of remote-bzr that we shipped in 1.8.2, the story
> is a bit different, though.  If this series makes things worse in a
> way your tests did not reveal, and if such a regression is not
> reported and/or cannot be fixed by 1.8.3 final, that will mean a
> real regression in the released version for them.
>
> If that ever happens, that would be the time for us to regret the
> hasty decision to merge remote-bzr in 1.8.2, justifying that with a
> "There wasn't anything working for interoperating with bzr, and here
> is one to do so; anything is better than nothing", and learn from
> that mistake (it is not an option to say "the 1.8.2 users chose to
> use contrib/ material that are clearly marked as sub-par quality
> with their own risk".  If we did not ship it in 1.8.2, they did not
> have to get burned with any regression and could have kept working
> with bzr a bit longer.  "Anything" is not necessarily better than
> "nothing").

> Hopefully, such a regression will not have to happen (for one thing,
> I would expect that the existing 1.8.2 remote-bzr user base would be
> very small).  Also I somehow have a feeling that it is very unlikely
> to happen, especially given your report:
>
>  (1) the series converts Emacs history without barfing; and
>
>  (2) you have some confidence in the conversion result after
>      inspecting at least a handful of key release points and trees
>      and metainformation match between the original and the
>      converted history.
>
> So let's go ahead and apply these directly on top of 'master', once
> we hear from Emacs folks and they are happy with it.  I'll queue it
> on 'pu' so that I do not have to go back to the list archive when it
> happens.