Add instructions on how to setup the dev environment
Add link to Season of Docs.
|Deletions are marked like this.||Additions are marked like this.|
|Line 5:||Line 5:|
'''NEW!''' This year we will be applying to Google's [[https://developers.google.com/season-of-docs/docs/|Season of Docs]]. For information about Mailman's project ideas, click here: [[../SeasonOfDocs2019|Mailman Season of Docs 2019]].
Mailman Developer Resources
Thank you for contributing to Mailman! Please also see the Mailman 3 release notes.
How to get started
Please read the git quickstart before doing anything else!
The Setup instructions will guide you through the process of setting up all the projects so you can start developing.
Contributing to Mailman, step 1: Git and Gitlab
Mailman 3's source code is published in git. Project management is available on Gitlab. We switched from Bazaar on Launchpad on May 4th, 2015. Previous to that, we switched from Subversion on SourceForge on June 22, 2007.
Please note: Mailman 2.1 development continues to be hosted in Bazaar on Launchpad.
For now, the Mailman 3 branch on Launchpad will continue to be available in read-only mode.
Contributing to Mailman, step 2: Contribution workflow process
A developer has an idea for an enhancement. They discuss it on the mailman-developers mailing list. For higher bandwidth discussions we can use irc (#mailman channel on irc://irc.freenode.net). Channel logs are available.
Developers can clone our git repository, push their own branches, and submit a merge request against the official branches.
- If the idea is appropriate for GNU Mailman and we decide to include it, FSF must get copyright assignments from the developer. See below. Do this early, since it can take some time to get all the paperwork to the FSF.
Branch development guidelines
- Branches should be self-contained: Include documentation, a NEWS entry, and tests. Ideally, there would be one bug for every branch.
Be sure your branch does not provoke any regressions. Run tox on your branch and be sure everything passes. Eventually, we'll enable CI on Gitlab so you'll know immediately whether your branch is ready for merging.
- Branches should be as small as possible. The smaller the branch the easier it is to review.
Contributing to Mailman, step 3: Copyright assignment
Mailman is a GNU project with the majority of the copyrights being held by the Free Software Foundation. We therefore request that developers who contribute code, assign their copyrights in their Mailman contribution to the FSF. To do this, you first need to submit a GNU copyright assignment request form containing some basic information, and then fill out the form that the FSF sends you. Please let us know after you've sent the second form so that we can track your contribution. The FSF often doesn't tell us in a timely manner when such forms have been received.
Mailman's developers are currently focused mostly on working towards the release of Mailman 3.0.
Mailman 2.2 -- 2.1 is the stable branch, now in maintenance mode
Mailman 3.0 -- 3.0 is the stable Mailman 3 release
Initiatives, proposals, ideas
Relevant RFCs, references, and standards
Here are some useful RFCs, references and drafts:
OWASP's password reset recommendations
Anti-spam and anti-backscatter
A talk given at a UK Unix User Group meeting. Look for the 5th abstract on this page.
The inevitable "...considered harmful" article.
- UK Joint Academic Network (JANet) provides network connectivity and services for UK
HE institutions has guidance to victims of backscatter.
...and to system adminstrators Spam Bounces Considered Harmful.
Mailman's own recommendations for controlling spam