[Mailman-Developers] Getting code in? (was: Storm based MemberAdaptor for Mailman)

[Barry Warsaw]

On Aug 9, 2009, at 3:35 PM, Andrew Grover wrote:

> Hi, I'm one of the GSOC mentors for Systers, all of whose students are
> working on Mailman enhancements. Some of these (Like Malveeka's) would
> be suitable for merging upstream, but the review and acceptance
> process is not clear.

Very cool to hear about your work!  Let's see if I can clarify  
things.  Eventually this ought to make it into the wiki.

> * Do people on this list regularly provide review of proposed
> enhancement patches?
> * Is there a set of people who explicitly ACK or NAK all proposed  
> patches?
> * Once reviewed, merging is via LP merge requests, right? Or does one
> do the merge request and *then* get reviewed?

I think the process should generally work like this:

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

* If the idea or approach isn't something the Mailman community thinks  
is worthwhile, we'll leave official participation at that.  Of course,  
this being open source and bzr being a DVCS, you're free to do  
whatever you want.

* If the idea is appropriate for Mailman, we must get copyright  
assignments from the developer.  Let's do this early, since it can  
take some time to get all the paperwork to the FSF.

* Branches should be as small as possible and still be self- 
contained.  They must include documentation, a NEWS entry, and for  
Mailman 3 they must include tests.  Ideally, there would be one bug  
for every branch you work on.  The smaller the branch the easier it is  
to review.  For Launchpad, we have a strict 800 line diff limit on  
branches.  I'm not sure if that's appropriate or not for Mailman, but  
please understand that anything over 1000 lines of diff gets very  
difficult and time consuming to review.

* When a branch is ready for review, create a merge proposal for it  
and email us here.

* One of us will review the code.  For Mailman 2.x, it will most  
likely be Mark.  For Mailman 3 it will be me.

* Once we've approved the branch, either Mark or I will merge it into  
the official trunks.  Currently only a few of us have write permission  
to the official branches.  I do hope more people become developers and  
reviewers!

> * More fundamentally, is Mailman currently accepting patches from
> external contributors?

Yes.  It's tough though, and I apologize in advance, but both Mark and  
I are very busy. I've tried to shed load by concentrating only on  
Mailman 3 and that seems to work for me (and hopefully MM3, which is  
making good progress).

> We have code to contribute. It's not perfect yet but we will make it
> better. We need some Official Mailman participation or our
> improvements will never make it out of our branch. Even a response of
> "we're not interested in X, thanks" would be much superior to no
> response at all.


Completely agreed!  Let's talk about your ideas and see which might be  
appropriate for inclusion.  I will really work at being more responsive.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 832 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20090809/4c59c65a/attachment.pgp>