Re: [Bug-mcron] [PATCH 00/33] Remove 'ed' hack and apply various cleanups.

[Dale Mellor]

On Sun, 2015-09-27 at 22:41 +0200, Mathieu Lirzin wrote:
> Here is a collection of patches which main purpose is to remove the ‘ed’ hack
> used for the C wrapper.  In addition I have done various “cleanups” mainly to
> reduce the number of top-level variables but not only...  I have implemented
> the ChangeLog generation as proposed in this previous email  [...]

Dear Mr Lirzin,

    thank you for your suggestions for shuffling the code around.  My
overarching observations are that

   * You have not fixed any problems.
   * You have not added any new functionality; apart from the license
changes the manual is exactly the same as it was before.
   * Your patches leave the presentation of the code in an inconsistent
state (most notably with regard to doc-strings).

   As per the Gnu guidelines, I'm not obliged to accept changes just for
their own sake, which all of this pretty much is.

   However, I have taken your suggestions on board lightly, mostly where
features introduced in recent incarnations of Guile make the code a
little easier on the eyes.

   The thing which causes me pause for deliberation is the introduction
of the forced use of guild and requiring guile version at or above
2.0.7.  Many distros don't ship with this by default, and it also forces
compilation (with ugly messages on-screen!) of individual crontabs when
mcron is invoked by end users.  I have been contemplating a special
branch in the repository for this, or making the package configuration
more sophisticated so that use of compiled code becomes a builder
option.  In the end both these are too messy to want to worry about, and
I'm not afraid of the future so I have taken on board your suggestion to
go down this path wholeheartedly.

   On a more general note, if you want to make contributions to projects
it would be good to have a definite aim in mind (specific bug fix or new
feature in the end product), and put forward patches which meet that aim
specifically rather than submitting a raft of micro-changes (that is a
good way to manage your local repository, but submissions to public
repositories need to be more considered).

   Very many thanks again; despite that this probably looks like a
rejection letter, your contribution and help in improving the product
really is appreciated.

Best wishes,
Dale

signature.asc
Description: This is a digitally signed message part