Hi Stefano,
> > Here's a proposed patch for automake.
> >
> Thanks. I have some minor nits and qualms with the patch, which I hope
> you can address in a re-roll.
Was this meant as an explanation to your fellow Automake maintainers,
or to me personally? If you meant me personally:
I am not a regular maintainer of Automake, and don't indent to become one.
Therefore I think my role is to
- describe the problem,
- provide a source code patch that following the GNU Coding Standards,
- send this patch to the appropriate mailing list or bug tracker.
Whereas the role of the Automake maintainers is to
- check the patch for soundness,
- apply the Automake specific coding styles,
- check whether other parts of Automake are affected by the same issue.
I am sending bug reports and small contributions to many packages,
from X11 over KDE to GNU teseq. I can spend time to find out about
the proper bug reporting channel, to retrieve the newest development
sources, and to test a probable fix. But it would be a waste of my time
to learn about the different "README-hacking"s of the various projects.
You, as a maintainer of your project, can apply your project specific
preferences 10 times faster than I could.
> First (and this is the only serious objection): could you please
> re-send your patch formatting with "git format-patch"? That will make
> it far more easy to apply.
Patches that are sent without git specific formatting can be applied
with "patch -p0 < mailfile" or "patch -p1 < mailfile".
> Automake don't have a version controlled ChangeLog anymore. Just write
> the ChangeLog entry in the commit log message.
> ...
> We use the format "topic: brief explanation" for the summary line
> ...
> Also, we prefer to have an explanation of the reason behind a change in the
> commit log, and links to the discussion/resources that have motivated it.
> ...
> In this case, I'd rewrite the commit log as follows:
Yes, please by all means, do this rewrite. You know the habits of
your project much better than I do. You also don't need to ask me
whether that's OK with me: sure it is.
> I think you have missed a couple of instances:
>
> - in doc/automake.texi: @samp{$(EXEEXT)} for the sake of Win32 or ...
> - in lib/Automake/XFile.pm: # Some Win32/perl installations fail to ...
> - in tests/compile2.test: skip_ "this test shouldn't run on a win32 ...
>
> Care to fix those too?
This too is in the domain of the package maintainer. I only reported
the 'compile' and 'ar-lib' scripts because these files happen to be
redistributed through gnulib.
Bruno
