[rear-devel] RFC: what should I do with my ideas for "rear 2.0"?
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
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).
SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard,
Graham Norton - HRB 21284 (AG Nuernberg)
More information about the rear-devel