[rear-devel] RFC: what should I do with my ideas for "rear 2.0"?

Schlomo Schapiro schlomo at schapiro.org
Thu Oct 29 18:12:31 CET 2015

​Hi Johannes,​

​sorry, my SUSE days are over since about 2010 when I turned off my private
data center at home.

debootstrap is the Debian tool to install a fresh distro into a chroot
environment. I forgot the name of the SUSE equivalent.​

​Therefore I can't really advise you very much on your proposal, especially
not with regard to the SUSE environment.

> As far as I can imagine right now,
> "rear mkbackup" and "rear recover" could keep their semantics
> but when rear is transformed into a generic installer
> the actual code would have to be changed very much
> and those changes will cause regressions at least
> in this or that special case.

​I don't follow you here. My vision for ReaR is to be a modular framework
where you have workflows that combine smaller actions into a meaningful

With this model I would expect you to refactor existing code to become
reusable for your case without harming existing functionality. You would
then be able to create new workflows to suit your purpose. All that with a
minimum of copy/paste and a maximum of code sharing.

You could for example add a "rear mkinstaller" and a "rear provision"
workflow that uses the things you need and adds new things that we don't
have yet.

BTW, the smaller a single component gets the easier it is also to write a
unit test for it.

> This is the reason why I am talking about "rear 2.0".

​I have seen to many projects fail to deliver a "rewrite" in a short time
(remember Samba TNG, mailman 3.0 ... ?)​

​so that I strongly prefer an evolution.

I would love to see automated tests for "certified" use cases and
environments. With that we probably would also feel confident to make
bigger changes in ReaR.

With that I would also prefer to get rid of the semantic versioning (a.b.c)
and come to a continuous release model - like a rolling distribution. IMHO
one of the major issues we have right now is that we don't release enough
and that making a release is a lot for work (thanks a lot to Gratien who is
doing that for the last years!!!). Automation for the win.

On the other hand with a major version number change
> a lot of other wanted stuff can be implemented
> (e.g. using "set -e -o pipefail" everywhere)
> i.e. everything where we fear regressions.

​Maybe those things can also be enabled in a softer way: First warn and
then fix the warnings and then enforce it.​

​Kind Regards,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pikachu.3ti.be/pipermail/rear-devel/attachments/20151029/992aff91/attachment.html>

More information about the rear-devel mailing list