Before contributing to this repository, please first discuss the change you wish to make via issue of this repository before making a change. Please note we have a code of conduct, please follow it in all your interactions with the project.
Open an issue when:
- You have questions or concerns regarding the project or the application itself.
- You have a bug to report.
- You have a feature or a suggestion to improve remotefs to submit.
If you have a question open an issue using the Question template.
By default your question should already be labeled with the question label, if you need help with your installation, please also add the help wanted label.
Check the issue is always assigned to veeso.
If you want to report an issue or a bug you've encountered while using remotefs, open an issue using the Bug report template.
The Bug label should already be set and the issue should already be assigned to veeso.
Don't set other labels to your issue, not even priority.
When you open a bug try to be the most precise as possible in describing your issue. I'm not saying you should always be that precise, since sometimes it's very easy for maintainers to understand what you're talking about. Just try to be reasonable to understand sometimes we might not know what you're talking about or we just don't have the technical knowledge you might think. Please always provide the environment you're working on and consider that we don't provide any support for older version of remotefs, at least for those not classified as LTS (if we'll ever have them). If you can, provide the log file or the snippet involving your issue. You can find in the user manual the location of the log file. Last but not least: the template I've written must be used. Full stop.
Maintainers will may add additional labels to your issue:
- duplicate: the issue is duplicated; the reference to the related issue will be added to your description. Your issue will be closed.
- priority: this must be fixed asap
- sorcery: it is not possible to find out what's causing your bug, nor is reproducible on our test environments.
- wontfix: your bug has a very high ratio between the difficulty to fix it and the probability to encounter it, or it just isn't a bug, but a feature.
Whenever you have a good idea which chould improve the project, it is a good idea to submit it to the project owner. The first thing you should do though, is not starting to write the code, but is to become concern about how remotefs works, what kind of contribution I appreciate and what kind of contribution I won't consider. Said so, follow these steps:
- Read the contributing guidelines, entirely
- Think on whether your idea would fit in the project mission and guidelines or not
- Think about the impact your idea would have on the project
- Open an issue using the
feature requesttemplate describing with accuracy your suggestion - Wait for the maintainer feedback on your idea
If you want to implement the feature by yourself and your suggestion gets approved, start writing the code. Remember that on docs.rs there is the documentation for the project. Open a PR related to your issue. See Pull request process for more details
It is very important to follow these steps, since it will prevent you from working on a feature that will be rejected and trust me, none of us wants to deal with this situation.
Always mind that your suggestion, may be rejected: I'll always provide a feedback on the reasons that brought me to reject your feature, just try not to get mad about that.
At the moment, these kind of contributions are more appreciated and should be preferred:
- Fix for issues described in Known Issues or issues reported by the community
- New file transfers: for further details see Implementing File Transfer
- Code optimizations: any optimization to the code is welcome
For any other kind of contribution, especially for new features, please submit a new issue first.
Let's make it simple and clear:
- Open a PR with an appropriate label (e.g. bug, enhancement, ...).
- Write a properly documentation for your software compliant with rustdoc standard.
- Write tests for your code. This doesn't apply necessarily for implementation regarding the user-interface module (
ui/activities) and (if a test server is not available) for file transfers. - Check your code with
cargo clippy. - Check if the CI for your commits reports three-green.
- Report changes to the PR you opened, writing a report of what you changed and what you have introduced.
- Update the
CHANGELOG.mdfile with details of changes to the application. In changelog report changes under a chapter calledPR{PULL_REQUEST_NUMBER}(e.g. PR12). - Assign a maintainer to the reviewers.
- Wait for a maintainer to fullfil the acceptance tests
- Wait for a maintainer to complete the acceptance tests
- Request maintainers to merge your changes.
In addition to the process described for the PRs, I've also decided to introduce a list of guidelines to follow when writing the code, that should be followed:
- Let's stop the NPM apocalypse: personally I'm against the abuse of dependencies we make in software projects and I think that NodeJS has opened the way to this drama (and has already gone too far). Nowadays nobody cares about adding hundreds of dependencies to their projects. Don't misunderstand me: I think that package managers are cool, but I'm totally against the abuse we're making of them. I think when we work on a project, we should try to use the minor quantity of dependencies as possible, especially because it's not hard to see how many libraries are getting abandoned right now, causing compatibility issues after a while. So please, when working on remotefs, try not to add useless dependencies.
- All protocols must be optional: If you're implementing a new file transfer, remember to create a feature to make your file transfer optional.
- Test units matter: Whenever you implement something new to this project, always implement test units which cover the most cases as possible.
- Comments are useful: Many people say that the code should be that simple to talk by itself about what it does, and comments should then be useless. I personally don't agree. I'm not saying they're wrong, but I'm just saying that this approach has, in my personal opinion, many aspects which are underrated:
- What's obvious for me, might not be for the others.
- Our capacity to work on a code depends mostly on time and experience, not on complexity: I'm not denying complexity matter, but the most decisive factor when working on code is the experience we've acquired working on it and the time we've spent. As the author of the project, I know the project like the back of my hands, but if I didn't work on it for a year, then I would probably have some problems in working on it again as the same speed as before. And do you know what's really time-saving in these cases? Comments.
In case you want to test the aws s3 client, you need to follow these steps:
-
Run containers
docker-compose -f "tests/docker-compose.yml" up -d --build -
Run tests with
cargo test --features with-containers
Thank you for any contribution!
Christian Visintin