Re: Survey: compatibility vs speed of rdiff-backup development

[Leland Best]

Hi,

Just my $0.02 ...

On Sat, 2023-03-04 at 12:08 +1100, Frank Crawford wrote:
> Just on the repository format migration option just consider that if
> automated, then when packaging it for RedHat, and probably other
> distributions, it should be non-interactive, and preferably easy to
> tell if it is required or not (for example if they did a reinstall).

If by "non-interactive" you mean something that happens automatically as, say,
part of the distribution's package upgrade/update process, I vote for a big
"No".

First, I don't see how the package manager stuff (i.e. scripts, etc.) could
possibly figure out reliably where all one's repositories are.  'rdiff-backup'
let's one create one _anywhere_.  There might be "system" backup repositories,
repositories created by individual users for their own use, testing
repositories, who knows what?  Some may not even be available at the time of
upgrade (removable drives, non- "auto mounted" network drives, etc.).

Second, I personally have had enough "new format upgrades" go horribly wrong
over the years (not with 'rdiff-backup', but in general) that I would much
rather be notified about the change ahead of time, then run some migration tool
(possibly built into 'rdiff-backup' itself?) at a time of my choosing.  That
way, I can back up my backups (good grief) before the migration just in case.

> 
> Also, as you have found, no one reads the release notes, so very few
> will read that they need to run anything for a migration, and so we
> will almost certainly need it to be done automatically, either by
> rdiff-backup, or just when upgrading the package.
[...]

Leading up to the mandatory migration, there should be a period of time where
'rdiff-backup' prints a prominent warning/notification about the migration every
time it's run.  During this time, 'rdiff-backup' should support both formats and
allow the migration tool to be run whenever it's convenient.

Again, just my $0.02 worth.

Cheers
Leland
-- 
-------------------------------------------------------------------------------
Leland C. Best      | Creationists make it sound as though a 'theory' is
lcbpublic@gmail.com | something you dreamt up after being drunk all night.
                    | -- Isaac Asimov
-------------------------------------------------------------------------------

[...]
> 
> Regards
> Frank
> 
> On Sun, 2023-02-26 at 18:49 +0100, EricZolf wrote:
> > Hi,
> > 
> > the results for this survery are not as nice and tidy as for the
> > Windows 
> > "bitness". The numbers are attached (with the summary as PDF for 
> > whomever doesn't have LibreOffice), and here is my interpretation:
> > 
> > 
> > == Introduction
> > 
> > For both questions, I've calculated the percentage for each option,
> > as 
> > well as the weighted percentage (i.e. according to number of
> > clients). 
> > I'll present these two numbers as C%/W%.
> > 
> > In the following lines, I'll summarize the summary and give you my 
> > conclusion, feel free to argue.
> > 
> > == Repository format
> > 
> > 88%/70% of the answers are OK with changing the repository format in
> > a 
> > non-backward compatible manner.
> > The two persons who didn't agree were actually more talking about 
> > archiving than about backup. If you need an archive solution, please 
> > make sure that you keep an old version of rdiff-backup parked
> > somewhere 
> > (together with its dependencies etc). With a bit of magic, it should 
> > even be possible to do this as part of the backup itself.
> > 
> > So for this point, my idea currently is to have an approach similar
> > to 
> > Android (and other frameworks): write snippets of code, of which the 
> > only purpose is to upgrade a repo from one version to the next, so
> > that 
> > by applying the snippets one after the other, you can upgrade any
> > repo 
> > to the current version. This could be done transparently when
> > creating 
> > the next backup _or_ with a specific "upgrade/update" command.
> > 
> > == API versioning
> > 
> > Here the result is less to my liking, but OK: 31/50% of the answers
> > are 
> > in favor of keeping the 200 API hence the compatibility with 
> > rdiff-backup 2.0. This will have a negative impact on my speed of 
> > development, but fair enough, I understand the comments asking for
> > more 
> > time to migrate all clients.
> > 
> > QUESTION: have you considered the side-by-side installation and the
> > new 
> > {Vx/y/z} place holders for versins as you gave this answer?
> > See 
> > https://github.com/rdiff-backup/rdiff-
> > backup/blob/master/docs/migration.adoc#side-by-side-installation
> > 
> > I'm asking again because the old code is really getting in my way,
> > and 
> > I'm not yet sure that I'll be able to keep the backward compatibility
> > without major risk to the code quality. I'll do my best, I haven't
> > yet 
> > tried hard, time will tell.
> > 
> > == Further thoughts
> > 
> > The format of the repository and the API are somewhat tied together:
> > new 
> > features might have an implication on the repo format, and might
> > require 
> > also API extensions to allow client and server to express the new 
> > feature. I'm still thinking about a good (and simple) way on how to
> > bind 
> > all these aspects. If someone knows of a good example on how to do
> > this, 
> > let me know...
> > 
> > Any further thoughts welcome, thank you so far for taking the time to
> > provide feedback,
> > Eric
> > 
> > 
> > On 11/02/2023 12:24, EricZolf wrote:
> > > Hi,
> > > 
> > > before I start for real with the development of version 2.4, I'd
> > > like to 
> > > get your opinion on the exact direction to take:
> > > 
> > > https://framaforms.org/compatibility-vs-speed-of-rdiff-backup-
> > > development-1676028206
> > > 
> > > I'd appreciate to get numerous answers and opinions. Feel free to
> > > also 
> > > discuss and argue on this mailing list.
> > > 
> > > I'll share the results on this list but they're public anyway.
> > > 
> > > Thanks, Eric
> > > 
>