Our new committer, Collin Funk, asks:
> Since I am not a GNU maintainer and have not
> used Savannah, please send any other rules, documentation, etc. that
> you think would be beneficial to read.
For Gnulib, we use Savannah only for the git repository and the news
announcements.
Regarding the git repository: When it appears to not respond, you can
- see whether it's a planned maintenance, at
https://hostux.social/@fsfstatus
- or ask the savannah admins on IRC (host libera.chat, channel #savannah).
The HACKING file is required reading. You can also occasionally browse the
GNU Coding Standards <https://www.gnu.org/prep/standards/html_node/index.html>.
> Also, for gnulib specifically all commits should have their patches
> sent to bug-gnulib right? I think I read that in the documentation,
> but I want to make sure I respect those rules. I very much appreciate
> the review/feedback on changes there too. Sometimes before I am
> confident enough with the change, such as the __pycache__ issue.
Community-wise, our habits here are:
- All patches are posted here, to the mailing list, for review or discussion
or (when already pushed) as a FYI. We don't like to see that patches have
been committed without notifying the mailing list.
- For review, allow us a week to do the review. Only if you got no reply
within a week, you can go ahead and push the change.
- It is sometimes impossible to address all review comments, for example
because different people have different ways of thinking or different
styles. In case of minor objections, our rule is "the one who does the
work decides".
- Strong objections, however, are a veto. If you already committed a patch,
and a strong objection comes up, you are expected to either fix it or
swiftly revert the patch.
Bruno
