Differences between revisions 77 and 97 (spanning 20 versions)
⇤ ← Revision 77 as of 2015-01-11 13:18:07 →
Size: 11199
Editor: maxking
Comment:
← Revision 97 as of 2023-02-25 16:13:48 → ⇥
Size: 11118
Editor: stephen@xemacs.org
Comment:
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
See the [[../MailmanOnLaunchpad|quick start]]. Thank you for contributing to Mailman! Please also see the [[../../Mailman3|Mailman 3]] release notes.
Line 6: Line 6:
== Contributing to Mailman, step 1: Bazaar and Launchpad == This year we will be applying to Google's [[https://summerofcode.withgoogle.com/|Summer of Code]]. For information about Mailman's project ideas, click here: [[DEV/Google Summer of Code 2023|Google Summer of Code 2023]].
Line 8: Line 8:
Mailman's source code is published in a publicly available revision control system called [[http://www.bazaar-vcs.org|Bazaar]] available through the code hosting and open source development service called [[http://launchpad.net|Launchpad]]. On June 22, 2007, we switched from using Subversion on SourceForge to the new repository, and while the old Subversion repository will still be available read-only, no new updates will be committed to it. Hosting the source code on Bazaar provides both the core developers and unofficial third party extensions much more freedom to hack on Mailman. == How to get started ==
Line 10: Line 10:
Here is more detail on how to [[../MailmanOnLaunchpad|develop Mailman code using Bazaar and Launchpad]]. Please read the [[../HowToContributeGit| git quickstart]] before doing anything else!
Line 12: Line 12:
Here are a list of [[../MailmanBranches|important official and unofficial branches]]. The [[../SetupDevEnvironment|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 [[http://git-scm.com/|git]]. Project management is available on [[https://gitlab.com/mailman/mailman|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 [[../MailmanOnLaunchpad|Launchpad]].

For now, the Mailman 3 branch on Launchpad will continue to be available in read-only mode.
Line 16: Line 24:
 1. A developer has an idea for an enhancement.  They describe it here and we can discuss general design issues, coding suggestions, decomposition of work into branches, etc. For higher bandwidth discussions we can use irc (#mailman channel on [[irc://irc.freenode.net|irc://irc.freenode.net]]).
 1. The Mailman community may be able to indicate in a non-binding way whether an idea is likely to be accepted, which can help the potential contributor decide to keep working with that in mind, or continue on however they like. (This being open source and bzr being a DVCS, everyone is free to do whatever they want.)
 1. If the idea is appropriate for Mailman, 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.		  1. A developer has an idea for an enhancement.  They discuss it on the [[http://mail.python.org/mailman/listinfo/mailman-developers|mailman-developers]] mailing list. For higher bandwidth discussions we can use irc (#mailman channel on [[irc://libera.chat|irc://libera.chat]]).
 1. Developers can clone our git repository, push their own branches, and submit [[https://gitlab.com/mailman/mailman/merge_requests|a merge request]] against the official branches.
 1. 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.
Line 20: Line 28:
==== Branch development guidelines ==== == Branch development guidelines ==
Line 22: Line 30:
 * Branches should be self-contained:  Include documentation, a NEWS entry, and for Mailman 3, include tests.  Ideally, there would be one bug for every branch.
 * Branches should be as small as possible. The smaller the branch the easier it is to review.  For Launchpad, we have a strict 800 line diff limit on branches, since anything beyond that gets very difficult and time consuming to review.

==== Branch review and merge ====

 * When a branch is ready for review, create a merge proposal for it and email the Mailman devel list.
 * A Core Mailman developer will review the code.  (For Mailman 2.x, it will most likely be Mark.  For Mailman 3 it will be Barry.)
 * Once we've approved the branch, either Mark or Barry will merge it into the official trunks.  Currently only a few of us have write permission to the official branches.		  * 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.
Line 37: Line 40:
Here are the collection of resources for people interested in the development of Mailman. Mailman's developers are currently focused mostly on working towards the release of Mailman 3.0.
Line 40: Line 43:
 * [[../Mailman 2.2|Mailman 2.2]]
 * [[../Mailman 3.0|Mailman 3.0]]		  * [[../Mailman 2.2|Mailman 2.2]] -- 2.1 is the stable branch, now in maintenance mode
 * [[../Mailman 3.0|Mailman 3.0]] -- 3.0 is the stable Mailman 3 release
 * [[../Mailman 3.1|Mailman 3.1]]
 * [[../Mailman 3.2|Mailman 3.2]]
Line 46: Line 51:
 * [[../PyCon 2015 Sprint|PyCon 2015 Sprint]]
Line 51: Line 57:
 * [[../Google Summer of Code 2011|../Google Summer of Code 2011]][[http://wiki.list.org/display/DEV/GHC12+Open+Source+Day+Hackathon|GHC12 Open Source Day Hackathon]]  * [[../Google Summer of Code 2011|Google Summer of Code 2011]]
 * [[http://wiki.list.org/display/DEV/GHC12+Open+Source+Day+Hackathon|GHC12 Open Source Day Hackathon]]
Line 56: Line 63:
 * [[../Summer of Code|Google Summer of Code 2006]]  * [[../Google_Summer_of_Code_2006|Google Summer of Code 2006]]
Line 58: Line 65:
== Initiatives and proposals == == Initiatives, proposals, ideas ==
Line 61: Line 68:
 * [[../Web Interface|Web Interface]]
Line 68: Line 74:
 * [[../ModernArchiving|Modern Archiving]]
Line 70: Line 75:
 * [[../REST Interface|REST Interface]]
Line 74: Line 78:
 * [[../ModernArchiving|Modern Archiving]] (currently HyperKitty in [[../Mailman 3.0|Mailman 3]])
 * [[../Postorius Web Interface|Postorius Web Interface]] (in [[../Mailman 3.0|Mailman 3]])
 * [[../REST Interface|REST Interface]] (a part of [[../Mailman 3.0|Mailman 3]] core)
 * [[http://blog.linuxgrrl.com/2012/03/14/mailman-brainstorm-2/|Mairin Duffy's blog ideas]]
Line 78: Line 86:

== Other developer information ==

Mailman is a [[http://www.gnu.org|GNU]] project with the majority of the copyrights being held by the [[http://www.fsf.org|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|GNU copyright assignment request form]] containing some basic information, and then fill out the form that the FSF sends you. Please [[mailto:mailman-cabal@python.org|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.
Line 109: Line 113:
  * [A talk given at a UK Unix User Group meeting. Look for the 5th abstract on [[http://www.ukuug.org/events/winter2005/programme.shtml|this page]].   * A talk given at a UK Unix User Group meeting. Look for the 5th abstract on [[http://www.ukuug.org/events/winter2005/programme.shtml|this page]].
Line 133: Line 137:
 * [[DEV/Google Summer of Code 2015|Google Summer of Code 2015]]
 * [[DEV/Google Summer of Code 2016|Google Summer of Code 2016]]
 * [[DEV/Google Summer of Code 2019|Google Summer of Code 2019]]
 * [[DEV/SeasonOfDocs2019|Mailman Season of Docs 2019]].
 * [[DEV/Google Summer of Code 2021|Google Summer of Code 2021]]
 * [[DEV/Google Summer of Code 2022|Google Summer of Code 2022]]
Line 146: Line 156:
 * [[DEV/PyCon 2014 Sprint|PyCon 2014 Sprint]]
Line 150: Line 159:
 * [[DEV/PyCon 2014 Sprint|PyCon 2014 Sprint]]
 * [[DEV/PyCon 2015 Sprint|PyCon 2015 Sprint]]

Mailman Developer Resources

Thank you for contributing to Mailman! Please also see the Mailman 3 release notes.

This year we will be applying to Google's Summer of Code. For information about Mailman's project ideas, click here: Google Summer of Code 2023.

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

  1. 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://libera.chat).

  2. Developers can clone our git repository, push their own branches, and submit a merge request against the official branches.

  3. 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.

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.

Version-specific resources

Mailman's developers are currently focused mostly on working towards the release of Mailman 3.0.

Sprints

Initiatives, proposals, ideas

Suggestions

People seem to have trouble figuring out where to make suggestions or feature requests. There is a suggestions page here, or you may wish to start a discussion on the mailman-developers list

Relevant RFCs, references, and standards

Here are some useful RFCs, references and drafts:

Best practices:

MailmanWiki: DEV/Home (last edited 2023-02-25 16:13:48 by stephen@xemacs.org)