devguide: bring contribution process page from redmine - v1 #7370
Conversation
That page existed only in our redmine. Updated and added a few things, like a paragraph about our expectations for feature contributors. Also updated links, contacts and some other processes that may have changed since last edition. Task OISF#4929
| Expectations | ||
| ------------- | ||
|
|
||
| If you submit a new feature that is not part of Suricata's core | ||
| functionalities, we would expect some commitment from you or the organization | ||
| who is sponsoring your work, before we could approve the new feature, as the | ||
| Suricata development team is pretty lean (and many times overworked). | ||
|
|
||
| This means we expect that | ||
|
|
||
| * the new contribution comes with a set of Suricata-verify tests (and | ||
| possibly unittests, where those apply), before we can approve it; | ||
| * proof of compability with existing keywords/features is provided, | ||
| when the contribution is for replacing an existing feature; | ||
| * you would maintain the feature once it is approved - or find someone who | ||
| can do that, in case you cannot; | ||
| * you respect our guidelines and processes. We appreciate community | ||
| contributors: Suricata wouldn't be what it is without them; and the | ||
| value of our tool and community also comes from how seriously we take all | ||
| this, and we ask that our contributors do the same! ;) |
There was a problem hiding this comment.
This is basically where I tried to incorporate what was discussed about better documenting some of our expectations.
There was a problem hiding this comment.
May need some rewording, but here are some thoughts:
you respect our guidelines and processes and accept that for a feature with the "community supported" status the team will try to spend minimal time on it to be able to focus on the core functionality. If for any reason you're not willing or able to commit to supporting a feature, please indicate this. Then team and/or community members can consider offering help. It's best to indicate this prior to doing the actual work, because we will reject features if no one steps up.
We should probably also add something about what it means if we say "support a feature"?
Codecov Report
@@ Coverage Diff @@
## master #7370 +/- ##
==========================================
- Coverage 75.84% 75.83% -0.01%
==========================================
Files 656 656
Lines 190093 190091 -2
==========================================
- Hits 144172 144159 -13
- Misses 45921 45932 +11
Flags with carried forward coverage won't be shown. Click here to find out more. |
|
|
||
| You can read more about our `Github workflow <https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Github_work_flow#Pushing-your-branch-to-your-github-repo>`_. | ||
|
|
||
| On github we have 'travis-ci' integration enabled. This means some automated |
| What branch to work on | ||
| ====================== | ||
|
|
||
| There are 2 active branches: |
There was a problem hiding this comment.
2 or 3, but ultimately its about new dev being for master only except in well exceptional cases :)
| <https://discord.com/invite/t3rV2x7MrG>`_. | ||
|
|
||
| Expectations | ||
| ------------- |
| who is sponsoring your work, before we could approve the new feature, as the | ||
| Suricata development team is pretty lean (and many times overworked). | ||
|
|
||
| This means we expect that |
There was a problem hiding this comment.
"The feature will be disabled by default, and if it brings in new dependencies (libraries or rust crates) those will also be optional and disabled by default."
|
Replaced by: #7373 |
Link to redmine ticket:
https://redmine.openinfosecfoundation.org/issues/4929
Describe changes:
like a paragraph about our expectations for feature contributors.
changed since last page edition.