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

Johannes Meixner jsmeix at suse.de
Fri Oct 30 10:50:02 CET 2015


On Oct 29 18:12 Schlomo Schapiro wrote (excerpt):
> My vision for ReaR is to be a modular framework
> where you have workflows that combine smaller actions
> into a meaningful task.

This is also my vision.

But my experience in reality is that this is not true
at least not true for those issues that I have to fix.

I wish I could more decouple the basic parts of rear
so that each part is more usable on its own.

> With this model I would expect you to refactor existing code
> to become reusable for your case without harming existing
> functionality.

Not possible for me in practice because existing code is
often a mix-up of the core functionality with various
special case handling (often without explanatory comment)
and usually I fail to understand why the code is as it is.
I can see what it does but I cannot see why it does it.

How should I refactor code that I do not fully understand?

When I refactor code that I do not fully understand
I will introduce regressions because I cannot test all cases
(in partiular SUSE does not test Red Hat or Debian/Ubuntu).

If I get a clear "go ahead" from the rear upstream authors,
I could start to refactor code as good as I can
(of course I try to avoid regressions)
but definitely I do need careful supervision.

> 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.?

I have no idea how to implement e.g. "set -u -e -o pipefail"
(I had forgotten '-u') first as warnings and then enforce it.

As far as I see when I implement e.g. "set -u -e -o pipefail"
I will introduce regressions because I cannot test all cases.

I never meant to start from scratch with rear-2.0.

My intent is to make rear-2.0 based on the current rear
but in practice I cannot keep all current rear functionality
as is. In theory this is possible but not for me (with my
limited knowledge) and not with reasonable effort.

A major version number change would make it obvious for all
current rear users that extra-careful testing is needed
and that this or that regressions are expected.

Furthermore with a major version number change we are able
to drop support for outdated things that also "mess up"
the current code (cf. "special case handling" above).

Kind Regards
Johannes Meixner
SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard,
Graham Norton - HRB 21284 (AG Nuernberg)

More information about the rear-devel mailing list