New Mailman wiki, Subversion (and other stuff)
For a while now, I've been trying to implement several project management improvements for Mailman, so that future development can be opened up to more people. As Tokio's and Mark's work has shown, there are very talented programmers out there that can contribute great stuff to Mailman if given a chance. Folks like Brad, JC, and Terri have also contributed greatly in ways other than with code, and I'd like to make it easier for others like them to help out.
With 2.1 in maintenance mode, planning for 2.2 gearing up, and my desire to once again jump start 3.0 work, we need all the help we can get.
While I'm still working on some things, there have been some good developments that I wanted to let you know about. First, Atlassian has offered free licenses and hosting for their excellent products Jira (issue tracker) and Confluence (wiki). I've used both for several years now and I think they are top-notch applications; Jira is definitely one of the best issue trackers I've used.
The wiki is now live, although not a lot of content has been moved there. Please see <http://wiki.list.org>. You can browse the wiki anonymously, but you must sign up to make any additions or changes. I would eventually like to move things like the Mailman FAQ, list of Mailman users, online documentation (where it doesn't overlap with the latex docs), and all community contributed content from the main web site to the wiki. If you've been looking for a way to contribute to Mailman that doesn't involve coding, here's your chance!
While Jira is live, there's nothing yet there. I've done only the minimal configuration for the issue tracker, but have not yet even set up any projects. Still, you can go to <http://bugs.list.org> to sign up or get a feel for the basics. Right now, I'm working on a conversion script that will take the SourceForge tracker data and massage it into a form that Jira can import. My plan is to move all issue tracking to Jira from SF's trackers.
One option to getting there faster is to just start Jira from scratch -- i.e. not import the SF issues. We could say that all 2.2 and 3.0 bugs and patches must go to Jira, but that 2.1 bugs would stay on SF. Then, when 2.1 is retired, we'd retire the SF tracker (that may not be for a long time though, given how pervasive 2.1 is). I'm interested in getting opinions about whether we should migrate all issues to Jira now, split the issues as described above, or take some other approach.
Now that Mailman 2.1.8 is out, I've gone ahead and converted the SF CVS repository to Subversion. You can checkout the entire tree via <https://svn.sourceforge.net/svnroot/mailman> but understand that that will checkout /everything/ (trunk, tags, branches, etc). If you just want Mailman 2.1, you can check out <https://svn.sourceforge.net/svnroot/mailman/branches/Release_2_1-maint>, or if you just want the trunk (2.2) you can check out <https://svn.sourceforge.net/svnroot/mailman/trunk>. You should no longer be able to check anything into the CVS repository. Not everyone who had write permission to CVS has been given Subversion write access. If you still need write access to Subversion and don't have it, please let me know.
Now that the conversion is complete, I plan on doing some repo house cleaning, such as moving the website stuff out of the main directory. After that, we can decide to leave the Subversion repository on SourceForge, or move it to Atlassian's hosting. The latter gives us the ability to control write permissions per directory and a hook to Fisheye for repo browsing through the web. Even if we want to move, we don't need to do that right away, as an svn dump/restore should do the trick.
Now that these changes have been made, I think it's time to start planning for Mailman 2.2. To that end, I would like most development artifacts to be recorded in the wiki, although discussion should still happen on mailman-developers (there's a 'Development' space and a link for 2.2 under that). I also plan on getting our data imported into Rosetta so we can coordinate i18n there; it's mostly my fault I've dropped the ball on this one.
Longer term, as we begin to restart Mailman 3 development, all those decisions will go in the wiki too. I have some other thoughts about Mailman 3 that I'd like to get feedback on, but as this message is getting fairly long anyway, I'll defer that for the time being.
So in summary, please check out the wiki. Let me know what you think about importing the SF issues into Jira. And check out the Subversion repository.
-Barry
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Apr 15, 2006, at 11:34 AM, Barry Warsaw wrote:
Now that these changes have been made, I think it's time to start planning for Mailman 2.2. To that end, I would like most development artifacts to be recorded in the wiki, although discussion should still happen on mailman-developers (there's a 'Development' space and a link for 2.2 under that). I also plan on getting our data imported into Rosetta so we can coordinate i18n there; it's mostly my fault I've dropped the ball on this one.
I would like to offer my help in the GUI modernization aspects of the
Mailman 2.2 plan. I've already done some work on a system in
production here at Reed that uses web.py and Cheetah to present an
alternate front-end, as well as applying our own CSS and templates
styles to the built-in Mailman administration and moderation pages.
Our system also "fakes" a unified member database by forcing use of
canonical internal email addresses and offers one-click subscriptions
to users who've already authenticated through our single-sign-on
infrastructure. As a part of that, I've also made some (horribly
hackish, but useful as a proof-of-concept) modifications to the built-
in CGI scripts' authN logic that allow them to check the existing
HTTP auth credentials passed along by the web server to determine if
a user has admin/mod privileges for a list.
We're pretty committed to Mailman, and have a number of systems I've
written which integrate with it either via the command-line
administrative tools or the internal Python API, so chance are we'll
be spending a lot of time working on these issues regardless.
Obviously, I'd prefer to maximize the chances that my work could get
pushed upstream, so I'd love to work closely with you guys to
coordinate priorities and coding standards.
Looking forward to working with you guys,
Lennon Day-Reynolds System Support Specialist Reed College -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin)
iD8DBQFEUoTfRtirLnfvQskRAm1KAJwIKh9mhzulbGbS8vEIbkOdlqUaywCghheB h+VEM+/s7uohEVDMhgmOXuI= =xnGf -----END PGP SIGNATURE-----
participants (2)
-
Barry Warsaw
-
Lennon Day-Reynolds