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

[Mathieu Lirzin]

Hello Dale,

Dale Mellor <address@hidden> writes:

>     thank you for your suggestions for shuffling the code around.  My
> overarching observations are that
>
>    * You have not fixed any problems.

Correction: I have not fixed any problem *you* care about.

>    * You have not added any new functionality; apart from the license
> changes the manual is exactly the same as it was before.

That is true.  However programming is an iterative process, so in order
to provide new features, it is necessary to make small improvements
(modularity, cleanups...) first.

>    * Your patches leave the presentation of the code in an inconsistent
> state (most notably with regard to doc-strings).

I have used a different way to format code which is based on a
conventional style used by GNU Guix & Guile, see:

  https://www.gnu.org/software/guix/manual/guix.html#Formatting-Code

I don't think reformating the whole code is a “good practice” since it
obfuscates the code history when doing ‘git blame’.  It is better to
adapt to a new formatting convention incrementaly while doing effective
code changes.

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

Supporting old distros is of course a hard problem.  For Mcron, IMO it's
OK to depend on the oldest Guile 2.x version shipped in Trisquel LTS or
Debian stable.

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

I guess we have differents standards.  I would recommend you to look at
what is actually done in other active GNU projects (Coreutils, Emacs,
Glibc, Gnulib, Guile, Guix, Hurd, ...) before giving these kind of
advices.  My submissions were done with a lot of care by separating
unrelated things, which is a good thing for a public repository.  Please
consider that you are maybe doing it wrong by picking/squashing various
mixed changes in single commits.  Each patch I have proposed had a
precise “aim” which was described in the commit logs I provided, but now
with the squashed commit c0a6eb14c257a47e9573631e5ac09e6528fba377 you
have made with:

  git commit -m "Taken on board suggestions of Mathieu Lirzin as per e-mails to 
the address@hidden mailing list around September 2015."

The purpose is of course nearly invisible (20 files changed, 1165
insertions, 674 deletions) since it requires to navigate through the
bug-mcron archives, choose the right “updated” version and verify that
the actual commit corresponds to the selected patch... what a pain!

Actually my main problem is actually that your way to deal with
contributors is disrespectful.  At multiple times I have asked you to
review my patches *before* pushing anything I have done in the repo:

  https://lists.gnu.org/archive/html/bug-mcron/2015-09/msg00001.html
  https://lists.gnu.org/archive/html/bug-mcron/2015-07/msg00005.html
  https://lists.gnu.org/archive/html/bug-mcron/2015-07/msg00002.html

and you have *again* chosen:
- to not communicate about what you disliked,
- to push an alien unpolished commit containing parts of my work
- to give the report *after*.

This communication problem lead me to the conclusion that it is not
possible for me to deal with you as a maintainer.

Good luck and godspeed,

--
Mathieu Lirzin