On 2016-01-09 05:24:41, Danny Edel wrote:
> Hello Antoine,
>
> thank you for your detailed answer. I will try to address inline.
>
> On 01/08/2016 10:45 PM, Antoine Beaupré wrote:
>> Borg has actually shown great API stability since it forked from
>> Attic. The change that occured was necessary, and was well documented
>> in the release notes and the manual. (It should have been documented
>> in the NEWS.Debian file in the Debian package as well.) It is also the
>> *only* one that happened in over 15 releases since the fork from
>> Attic. We can even still convert older, prehistoric attic repositories
>> to borg without data loss.
>
> My statement that borgbackup does not make any compatibility guarantees
> was a quote taken from the top-level README.rst (near the bottom of the
> file), not by inspecting the actual source code history. If it is no
> longer accurate, you might want to update that paragraph in the upstream
> README, since this statement reads very different.
>
> I apologize if I made the wrong conclusions, and I think we can find a
> good solution to this.
No, you reached the right conclusions, I believe, from the information
you had on hand. I feel that those warnings are true and accurate, after
all, compatibility *was* broken in 0.29. Those warnings are there to
give devs the freedom to do exactly that, and to emphasize that borg is
not yet 1.0.
Yet I felt it important to pinpoint that it's only *one* breakage, and a
small one too. So taking the package out of Debian is totally out of
proportions. :)
Hopefully, that paragraph *will* be updated when 1.0 is released of
course.
[...]
>> But tons of backup software in Debian have that behavior: unison was
>> already mentionned, but rdiff-backup also has the same problems. That
>> is why we have backports: when the server side upgrades, we upgrade
>> the clients to the backports version. It's annoying, but it works, and
>> rdiff-backup has been in Debian for a long time. Those other backup
>> softwares are way more popular, sometimes by orders of magnitude, than
>> borg:
>
> I understand this solves the issue about writing to a new
> (testing/unstable) server with an old (stable) client. I know this is
> irrelevant if borg-1.0 gets released before stretch (which I hope it
> does), but can you clarify how borg does/will handle "old server, new
> client"?
I believe it is the same way than "new server, old client", ie. it
fails. But that is only around the 0.29 boundary, mind you, not
something that happens at every version (like rdiff, fwiw).
[...]
>> I was looking at backporting borg from stretch to jessie, but if the
>> maintainers are going to remove it from stretch, i'm certainly not
>> going to bother, and that would be a shame...
>
> A backport would be really nice to have, so please don't give up on this
> yet. In essence, all I want is a solution on how to ensure that users
> don't get surprised.
Right, I understand that. Unfortunately, as a Debian maintainer, there
is little you can do there: you are stuck with whatever upstream is
doing, to a certain extent. If upstream decides to surprise their users,
you will have to communicate that surprise to your users somehow. The
typical way is through NEWS.Debian, not through removal requests, as
*that* would be an even more obscure and traumatizing event. :)
>> Finally, keep in mind that this is a problem only in Debian, and only
>> if we have multiple, incompatible versions of borg in
>> Debian. (Non-debian installs can use virtualenvs to install as many
>> borg versions as they want.) Right now, we only have one version
>> (0.29.0-2), and it's compatible between unstable and testing. If
>> testing gets released right now, stable, testing and unstable are all
>> compatible, and we have absolutely no problem.
>
> Agreed. Currently there would not be a problem, but it will be one when
> upstream releases another API-breaking release. The main point of this
> ticket is to figure out how to be prepared for that next time it happens.
I would personnally suggest to "cross that bridge when we get
there". Right now there is no problem, and the odds are that there will
be little more problems in the future, short of the 2.x release which is
probably months if not years in the future.
So we have time. And I believe the answer is, "let users deal with it,
don't remove borg, and use the NEWS.Debian luke". ;)
>> Furthermore, it's very likely that borg 1.0 gets released before
>> stretch, so all those arguments will be completely irrelevant because
>> borg *will* be API stable.
>
> Yes that would be perfect.
If people here are interested, I think it could even be possible to have
a 1.x.y release branch where only "debian-critical" (security and data
loss) issues are committed. Upstream has shown concern about the amount
of manpower necessary to maintain that, but if people in the Debian
project here are willing to commit to that, it would be perfectly
possible to coordinate such releases with upstream so that Debian is a
known quantity in their release pattern.
[...]
> Let's resolve this situation first and close this bug (so the
> testing-autoremoval is disabled), then create the backport.
>
> Let me try to summarize to check if I understood you correctly:
>
> 1. The incompatibility warning from README only affects the network
> communication between different versions, not the on-disk format
Correct.
> 2. Borgbackup already makes the "read back your old backups with a new
> software version" promise, all the way back to attic repositories.
To be honest, it's not exactly a "promise", but it's something we are
definitely careful about. I actually wrote that attic to borg conversion
code myself to ensure that migration path exists. I made it so there is
a framework in which we can write future migrations like this in a
user-consistent way (borg upgrade).
> 3. By using your backport, #1 will be solvable by the enduser directly
> without having to resort to non-apt-managed software installation.
Correct.
> #1 would in my opinion downgrade this ticket from serious to normal, and
> #2 would make my point of "not ready for Debian stable" void.
> #3 would classify as a solution to #1, closing the bug.
>
>
> If that is accurate, I'd consider this more of a misunderstanding than
> an actual problem, and the solution would be a well-clarified
> README.Debian that explains to the end-user that for network
> communication they need to run the same version on all hosts (using
> backports when neccessary), and - from now on - NEWS.Debian entries
> whenever any incompatibilities arise, so users get notified at the "apt
> upgrade" stage and can abort the update if needed.
That is an accurate description, I believe.
> I again apologize for any misunderstandings and look forward to your
> clarification.
No apologies necessary. Thanks for summing it up, I hope my comments
were useful.
A.
--
L'ennui avec la grande famille humaine, c'est que tout le monde veut
en être le père.
- Mafalda
