bug-autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ENHANCEMENT]Autoconfig.pdf


From: Eric Blake
Subject: Re: [ENHANCEMENT]Autoconfig.pdf
Date: Wed, 02 Jul 2014 08:48:06 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

On 07/01/2014 11:50 PM, Arthur Schwarz wrote:
> I have finished what I can only consider as a World Class Enhancement;
> neglecting only that an enhancement in one person's eye is trash in
> another's. Sigh.
> 
> I am including an Open Office document (.odt) and a pdf document for

That's a bit much; the preferred form for modifying the docs is a patch
to the texinfo sources:

http://git.savannah.gnu.org/cgit/autoconf.git/tree/doc/autoconf.texi

It's also easier to see your proposals in diff format.  Your attachments
show just an end result, but not how to get there from the current state
of things.  That's a maintenance burden, which requires time from
whoever would actually apply your patch; a good rule of thumb in open
source is that the less time you require from a maintainer to do grunt
work, the more likely your patch is to be reviewed and applied.

Here's a bit more about submitting patches:

http://git.savannah.gnu.org/cgit/autoconf.git/tree/README-hacking

However, I do appreciate that you've taken initiative, and hope that you
can take this further by resubmitting the work as a patch against the
texinfo sources.

> rewritten prefatory sections of the automake User's Manual. Please interpret
> this as an "If I were doing the ..." knowing full well that you are doing
> the work and not me. If you accept any non-trivial portion of my work for
> future releases of the User's Manual then you have to tell the FSF to send
> me forms to turn over my copyright (to the work) to the FSF.

Yes, we can start the FSF paperwork process.  I'll send a followup mail
to you off-list.

> 
> There are a few notes (which, I fear, only one of us will think relevant).
> 1: You have no Colophon defined. If you think it useful to have I've left a
> placeholder for it.

What do we need it for?  A good patch explains not only what you've
done, but why it is a good thing to have changed.

> 
> 2: The libtool descriptions I've left hanging. I briefly looked at the
> libtool User's Manual and noticed that it specifies and uses libtoolize and
> libtoolize has a slew of input files. No time to look at them right now.
> 
> 3: The automake build diagram in the existing User's Manual incompletely
> specifies the output files. I think that there (must be?) one or more
> Makefile(s) generated but they are not specified.

The fact that you have multiple points suggests that you should break
your work up into smaller pieces.  It's easier to review 100 patches
that do one small thing each than it is to review 1 patch that does 100
things all crammed into one submission.


> 11: I ran out of time. If the current submission looks good then I'll try to
> continue this weekend (?). Otherwise, well, I will have missed the target.
> Sigh.

I echo the sentiment; I have not had time to look further at your odt or
pdf submission, just your summary of what you have tried to do.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]