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

Gratien D'haese gratien.dhaese at it3.be
Fri Oct 30 11:51:19 CET 2015


 I have no problems with a rear-2, but currently I have no clue what you 
 to modify at all? Perhaps, prepare a design document first? So, we 
 coders can follow you reasons and ideas.
 Perhaps, it would be better to fork rear-2 from rear to avoid 
 interruption for
 those who use rear in production?
 Afterwards, we could merge the branches again. Or not, if it deviates 
 too much.
 If rear-2 becomes usable and successful we could leave the rear-1 
 branch as is.

 However, if it is a matter of *not enough* documentation in the code - 
 why not deal
 with that and ask us what you do not understand? More comments will not 
 hurt of course.
 Some parts not written by the core devs are difficult to read, but 
 rewriting everything to your
 taste is very time consuming and as nobody wants to pay for it we leave 
 it as it is (if the
 code works). We just fix what is broken.

 Personally, I would like to extend documentation as that is what our 
 users would like to see
 according to our poll results (I know I should publish these - in a day 
 off perhaps).

 best regards,

 On Fri, 30 Oct 2015 10:50:02 +0100 (CET), Johannes Meixner 
 <jsmeix at suse.de> wrote:
> Hello,
> 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

 Gratien D'haese
 IT3 Consultants bvba
 Vennestraat 15, B-2560 Nijlen

More information about the rear-devel mailing list