How best to offer patches to riofs ?

[ThePythonicCow]

I'm using riofs in a "Library" of a few dozen large (typically 100 Kb to 2 Gb) files for download by users of a web site I administer. I have riofs running on a small Linode.com nginx web server, offering up files from an AWS S3 backing store.

I have several fixes and tweaks for riofs that I'm coding up, and that I'd like to offer to y'all, the riofs developers, for your consideration. For example:

• I have a few line reworking of the LogLevel enum, to fix a build bug
• I have an extension to the max cache directory size, to allow caches larger than 4 GBytes (essential to minimize my download bandwidth costs from AWS S3)
• I'm working on a (not much coded yet) persistent AWS ETag based way to preserve my cache contents and ranges, across restarts of the riofs server, to further reduced AWS bandwidth costs
• I have a couple of modest code cleanup and reorganizing changes that y'all might, or might not, find desirable.

The question for this here Issue: How would you prefer to see these proposed patches - perhaps as email patches, perhaps as pull requests from https://github.com/ThePythonicCow/riofs, perhaps some other way, ... ?

[ThePythonicCow]

So far I have the following stack of eight (8) patches, in quilt (my favorite tool for managing patch sets):

1. git_ignore_INSTALL_file
2. git_ignore_quilt_patches
3. fix_automake_warnings_and_breakage
4. fix_const_warning
5. fix_typedef_enum_LogLevel_compile_error
6. add_DEFAULT_SOURCE_another_gcc_flag
7. specify_which_XOPEN_SOURCE_level_to_use
8. huge_max_cache_size

The first seven (7) fix small build failures and warnings that I happened to encounter, and the last one allows to specify max cache sizes up to 4096 terabytes, rather than the existing limit of 4 gigabytes.

The main patch I am intend on, the ETag based persistent cache store, remains to be done.

[wizzard]

Hello,

please submit patches one by one, so I could review and test them.
It would be great, if you provide simple tests for your code (especially for your ETag patch) - we have python tests there, if you don't mind please add / extend existing tests.

Thank you!

[ThePythonicCow]

Extending the python tests - good idea.
Submitting patches one by one - yes - I'm a firm believer in that.

Do you prefer that I email the patches to you, or that I check them into my git clone of riofs and ask you to consider pulling them ?

[wizzard]

Please use Pull Request feature (commit changes to your clone and then use GitHub web site Pull Requests), so we can see the changes and discuss / clarify patches if needed.

Thank you!