On 06/02/2015 10:24 AM, Arthur Schwarz wrote: > A coupla' issues. I don't know Texinfo. I have included an extensive > revision of the TAP testing cycle as a pdf file, downloaded from an Open > Office Document. While that may work, it is tedious to maintainers. We have to figure out which text you added or removed, then find the same text in the upstream texinfo file and make the same edits. And being a pdf, it may be hard to copy and paste the changed text, making it all that harder. You might make it easier by using color highlights or strikethrough notations to call attention to your edits, but it is still not as trivial as just having those edits already made in patch form against the original upstream texinfo file. If you want your patches to go in, it really WILL be better for you to figure out how to directly patch the texinfo file. It's not that hard to figure out - it is a plain text representation with fairly obvious markup for the most common tasks. And we are more than willing to help you with markup questions or with proof-reading, if we can start from a patch that gets us 90% of the way to a final version without having to do lots of copy-and-paste gyrations. But if you just dump a .pdf file of "here's the final product" without actually patching the upstream source file, it will probably just be ignored, because in that case, you'd have done only 10% of the work instead of 90%. Like it or not, free software works on a meritocracy principle, where the patches that get applied are the ones written by people persistent enough to make the maintainer's life easy. For comparison, we prefer that someone says: "here are the changes to your .c file to fix a bug", rather than "here is a complete .c file that includes bug fixes but you have to locate what changed" or even "here is a new binary that was compiled from a fixed .c file, but you have to reverse engineer the binary to figure out what the changes were". -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org