Closed claunia closed 7 years ago
Let's say I'm very much looking for real collaboration :)
Ideally, I'd start accepting pull requests, smallish at first but then accept large ones with a common style. I'd definitely make reviewing a priority. I'd like to get to the point where I'd share ownership of the project as well. I've wanted to do that for years.
As for what you want to do, I guess we can talk about items in issues or example pull requests. I always try to be responsive to people providing actual code.
As for the licenses, I'm not a lawyer but I'd rather not get sued :). Other than that, anything goes.
Let me know what you think.
That now I only need to understand your API a little ;)
Do you need everything to have a stream or do you suffice with something like decompress(byte[] input, byte[] output)?
I have two algorithms prepared to be glued to SharpCompress as long as I know where and how!
For actual algorithms they should be Stream objects. It's only way to really interact with bytes from arbitrary sources.
There should be plenty of examples for that. Of course how the algorithm functions is always different but surely they act on chunks.
Being mostly algorithms used for disk images they are mostly chunk based. Not only that I need them to return the whole chunk at a time. I tried to check deflate and bzip2 as examples but they are several orders of magnitude more complex than what I have (160 lines in a static class). I'll try something and send a pull request and let's see how good it fits.
There you have #168 tell me what you think.
I may suggest a series of ideas, I've seen used in big projects, that may do easier for others to collaborate.
Usually there are a series of rules in a CODING file so I'll enumerate the ones I think the most important: 1.- Define a coding style, and use it extensively. VS2015 provides reformatting and templates to apply these. Choose your favorite. 2.- Define a standard header, so all files can be known, at a glance, their license and copyright owners. 3.- Include all applicable licenses. I've seen you have files in MPL and only MIT is included in the project root. 4.- Remember that only compatible licenses can be mixed and the most restrictive one is used. For example code containing LGPL, MIT and BSD generates an LGPL library. LGPL and APSL cannot be mixed. 5.- Write down your idea of an API and code organization. You know where to add an archiver, where to add a compression algorithm. You can write it down in seconds, external collaborators need minutes or hours to find out.
With this I think you'll attract more collaborators imho.
In the meantime thanks for accepting my patch, I'll prepare a few more in the next weeks.
I've tried to put things in a Resharper DotSettings file but you're right I haven't explicitly done anything about documenting how to contribute.
Feel free to suggest things like what you said in a PR :)
Let's say I have an application DiscImageChef. Let's say my application needs to decompress data, from several algorithms, that may or may not, have ever been used in an archiver (e.g., ADC, Teledisk). Let's say I would like to use your library and implement those algorithms for the sake of your greatness (and not reinventing the wheel). Let's say sometimes those algorithms will be ugly, propietary, or need to be reimplemented (no copy&paste, but read&understand&rewrite) from archaic libraries in other opensource licenses (GPL and LGPL) Let's say I need pull requests to be accepted as fast as possible.
What can I do to satisfy your needs so you can satisfy my needs and we all get happy along together forever 😃