|
Size: 5130
Comment:
|
Size: 9999
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| #pragma page-filename DEV/versions/786630 | #pragma page-filename DEV/versions/8978643 = [[http://wiki.list.org/display/DEV/2008/09/02/Tracker+Migration+to+Launchpad+Scheduled|Tracker Migration to Launchpad Scheduled]] = |
| Line 3: | Line 4: |
| == Source code revision control == Mailman's source code is publish 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. |
== Contributing to Mailman, step 1: Bazaar and Launchpad == 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. |
| Line 10: | Line 11: |
| == Versions specific resources == | == Contributing to Mailman, step 2: Contribution workflow process == 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]]). 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. ==== Branch development guidelines ==== * 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. == Contributing to Mailman, step 3: Copyright assignment == 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. == Version-specific resources == |
| Line 16: | Line 31: |
| == Sprints == * [[../PyCon Sprint 2009|PyCon Sprint 2009]] * [[../Google Summer of Code 2008|Google Summer of Code 2008]] * [[../Summer of Code|Google Summer of Code 2006]] |
|
| Line 17: | Line 36: |
| * [[../New Logos|New Logos]] * [[../GPLv3|GPLv3]] |
|
| Line 22: | Line 43: |
| * Web U/I: [[../StyledPages|Using CSS]], [[../TemplatingNotes|Adding templating]] | * [[../Web Interface|Web Interface]] * [[../ModernArchiving|Modern Archiving]] * [[../Stable URLs|Stable URLs]] * [[../REST Interface|REST Interface]] * [[../Patches|Patches]] * [[../ReplyTo|ReplyTo]] * [[../Usability|Usability]] == Suggestions == People seem to have trouble figuring out where to make suggestions or feature requests. There is a [[../suggestions|suggestions]] page here, or you may wish to start a discussion on the [[http://mail.python.org/mailman/listinfo/mailman-developers|mailman-developers list]] |
| Line 24: | Line 54: |
| Google did a [[http://code.google.com/soc/|2006 Summer of Code]]program in 2006, and Mailman was a sponsor. See the [[../Summer of Code|Summer of Code]] page and [[../Mailman 2.2|Mailman 2.2]] page for more 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. |
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 29: | Line 57: |
| Here are some useful references: | Here are some useful RFCs, references and drafts: |
| Line 34: | Line 62: |
| RFCs and drafts: | * [[http://www.faqs.org/rfcs/rfc3834.html|RFC 3834 - Recommendations for Automatic Responses to Electronic Mail]] * [[http://tools.ietf.org/html/rfc5064|RFC 5064 - The Archived-At Message Header Field]] '''draft''' * [[http://www.faqs.org/rfcs/rfc2033.html|RFC 2033 - Local Mail Transfer Protocol]] * [[http://www.ietf.org/rfc/rfc4871.txt?number=4871|RFC 4871]][[http://www.dkim.org|DomainKey Identified Mail (DKIM)]] * [[http://www.openid.net|OpenID]] * [[http://www.faqs.org/rfcs/rfc1893.html|RFC 1893 - Enhanced Mail System Status Codes]] * [[http://www.faqs.org/rfcs/rfc2034.html|RFC 2034 - SMTP Service Extension for Returning Enhanced Error Codes]] * [[http://en.wikipedia.org/wiki/Bounce_Address_Tag_Validation|Bounce Address Tag Validation (BATV)]] * [[http://www.ietf.org/id/draft-shafranovich-feedback-report-07.txt|Extensible Format for Email Feedback Reports]] Best practices: |
| Line 36: | Line 73: |
| * [[http://www.faqs.org/rfcs/rfc2033.html|RFC 2033 - Local Mail Transfer Protocol]] * [[http://www.dkim.org|DomainKey Identified Mail (DKIM) draft specs]] * [[http://www.openid.net|OpenID]] |
* Anti-spam and anti-backscatter * [[http://wiki.exim.org/EximAutoReply|How To Do Autoreplies Without The World Hating You]]. * <<Verbatim([)>>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]]. * [[http://www.dontbouncespam.org/]] * [[http://spamlinks.net/prevent-secure-backscatter.htm]] * The inevitable [[http://mayfirst.org/?q=node/180|"...considered harmful" article]]. * UK Joint Academic Network (JANet) provides network connectivity and services for UK HE institutions has [[http://www.ja.net/services/csirt/advice/policies/collateral-spam.html|guidance to victims of backscatter]]. * ...and to system adminstrators [[http://www.ja.net/services/csirt/threats/bounce.html|Spam Bounces Considered Harmful]]. * [[http://mipassoc.org/batv/|Bounce Address Tag Validation (BATV)]] * Mailman's own recommendations for [[SEC/Controlling spam|controlling spam]] |
[[http://wiki.list.org/display/DEV/2008/09/02/Tracker+Migration+to+Launchpad+Scheduled|Tracker Migration to Launchpad Scheduled]]
Mailman Developer Resources
Contributing to Mailman, step 1: Bazaar and Launchpad
Mailman's source code is published in a publicly available revision control system called Bazaar available through the code hosting and open source development service called 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.
Here is more detail on how to develop Mailman code using Bazaar and Launchpad.
Here are a list of important official and unofficial branches.
Contributing to Mailman, step 2: Contribution workflow process
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).
- 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.)
- 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.
Branch development guidelines
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.
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 knowafter 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
Here are the collection of resources for people interested in the development of Mailman.
Sprints
Initiatives and proposals
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
Other developer information
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.
Relevant RFCs, references, and standards
Here are some useful RFCs, references and drafts:
A Highly Scalable Electronic Mail Service Using Open Systems (Christenson, et al)
RFC 3834 - Recommendations for Automatic Responses to Electronic Mail
RFC 2034 - SMTP Service Extension for Returning Enhanced Error Codes
Best practices:
- 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