#1387 Issue closed: BACKUP_PROG=rsync and rear mkbackup -v prints the verbose rsync output on the terminal

Labels: bug, fixed / solved / done

schlomo opened issue at 2017-06-20 14:14:

I would rather see that verbose output in the log and enjoy the periodic XXX MB stored messages that are now hidden in the quickly scrolling rsync output.

gdha commented at 2017-07-11 06:04:

@schlomo is this resolved with your commits?

schlomo commented at 2017-07-11 07:18:

Yes, I fixed this one. It should auto-close with the merge.

gdha commented at 2017-07-11 07:23:

@schlomo only if you write close #1387

schlomo commented at 2017-07-11 08:00:

@gdha according to https://help.github.com/articles/closing-issues-via-commit-messages/ "fixes" also should work, together with a lot of other common words.

jsmeix commented at 2017-07-11 08:52:

@schlomo @gdha
I cannot find any of the commits
https://github.com/rear/rear/commit/ae30d617ec4048a3c0a3943844528d0e920eff73
https://github.com/rear/rear/commit/fe91b4fa705005dfc2c277bb820332ce8e25b922
https://github.com/rear/rear/commit/25932a1b4ea587ed2f1f4f23bbeb533fcc749c8f
in a current "git clone https://github.com/rear/rear.git"
but I can find the last commit
https://github.com/rear/rear/commit/2b40e0fa845ef5e29184c5ec356bcd469790ec83
in the schlomo-2017-06 branch but not yet in the master branch.
To get the issue fixed in ReaR 2.2 the schlomo-2017-06 branch
would need to be merged into the master branch.

gdha commented at 2017-07-11 10:26:

@schlomo @jsmeix sorry I must have been confused with the mails I got (not used to work with branches within rear master itself)

jsmeix commented at 2017-07-11 11:53:

I think it depends on what we think
which exact conditions must be fulfilled
to set an issue as 'closed'.

On the one hand the fix is there (in the schlomo-2017-06 branch)
but on the other hand the fix is not yet normally available
for ReaR users who use the current GitHub master code
via 'git clone' as described on relax-and-recover.org

I think an issue could be 'closed' when the fix is in a branch
but I think to set an issue to 'fixed/solved/done' the fix
must be available as usual in the master branch.

FYI:
At openSUSE we have the same kind of problem with bugfixes:
When a Bugzilla bug entry is closed as "fixed" it means
a fix was submitted into whatever appropriate project
but that does not mean the fix is available for the users.

schlomo commented at 2017-07-11 12:04:

@jsmeix good point. I think if we "just" use GitHub it all works out well:

  • A user creates an issue
  • Somebody creates a fix and closes the issue in the commit message
  • As soon as this commit is merged into master, the issue will auto close

As a result the user gets all the feedback he needs. And the issue is only closed when the fix is actually in master and available in the next release or snapshot build.

[Export of Github issue for rear/rear.]