Mailman 3 May 2007 - Mailman-Developers

Should we move to Bazaar?
by Barry Warsaw 10 May '07

10 May '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm very encouraged and excited by all the interest from developers who want to get involved in the Mailman project. I've always wanted to broaden the sphere of developers beyond the current core three (though I can't say enough about the great job Tokio and Mark do). I think this is a good time to ask whether we should move from Subversion to Bazaar <http://www.bazaar-vcs.org> for our source code revision control system. There are plusses and minuses, and I will not make the decision unilaterally (unless you want me to. :). Certainly, Tokio's and Mark's opinions are very important here because they are currently doing exceptional work on the 2.1 branch and I don't want to jeopardize that! Let me outline my thinking here and get your feedback. Bazaar is a distributed version control system. This is really the crucial different between centralized systems such as Subversion and CVS, and it's the main draw for wanting to switch. Using a dvcs such as Bazaar really changes the way we as developers work on the code, and the way other non-privileged developers can interact with the project. The biggest differences are that you can work completely disconnected from the central server, and you need have no special permissions to have *and publish* fully revision controlled personal branches. The cons are that it's not as mature as Subversion or CVS, but I have confidence that it's pretty stable. It has not yet reached a 1.0 release, but I think that's coming soon. (It's been ported to *nix, OS X, and Windows, and it's written in Python if that matters). It does not have all the features of Subversion (e.g. nested branches or externals), but it has enough to make it useable for everyday development. It takes some getting used to for existing Subversion and CVS users, and the documentation is not as good. But I think people can pick it up fairly quickly and there's a lot of effort being put into it. Full disclosure: my company Canonical is the driving force behind Bazaar, and uses it internally for all our development. It's free software though, so no worries on that front. I would not recommend it for the Mailman project though unless I thought it could solve some real problems, that it was stable enough to rely on, and that Mailman would benefit from using it. Having insiders to heckle helps, but it wouldn't be enough if that's all there was. What problems does it solve? Well, I'm /still/ struggling to merge in the work I did while on the train to PyCon in Dallas because of all the contortions I had to go through to work off-line for a couple of days. Bazaar solves this by allowing me to do everything I need to do while completely disconnected, except push my changes to the master branch. I could have committed, branched, merged, reverted, etc. all in a completely revision controlled way while off-line, and then I could have merged all my changes back to the master branch when I got back on-line. It also solves a problem I have of many live branches. Branches in Bazaar are cheap, unlike in Subversion. This means I can easily create branches for my Elixir experiments, for the move to eggs, for playing with 5 different templating engines, etc. And it's easy to merge between these. I can also have private branches that need never see the embarrassing light of day until they are stable enough to merge into the main line. What problems does it solve for you? Well, if you're a developer wanting to contribute to Mailman but we don't know you well enough to give you commit privileges, you almost don't care. You can branch from the main branch, and have a fully revision controlled private branch at your disposal. You can do commits, branches, merges, etc. on your local branches. You can even publish them via http, bzr+ssh, or sftp. Why is that cool? Well, say you created the best damn templating patch EVAR and you wanted everyone to see it. Just publish your branch (or create a bundle -- a mailable tarball-like unit of your changes) and pass around the URL. Anyone can then take a look at your branch, and the core developers can merge them into the mainline if we like them. It's a great way for new developers to earn some street cred with minimal admin overhead. And if we /don't/ like your changes, you do not have to maintain them as a disembodied patch. You can say "screw the Mailman guys, here's my cool fork" and have a fully revision controlled version of your own, in a way that's much easier to track with upstream than with Subversion or CVS. One more thing. If we move to Bazaar, I would host the branches on Launchpad.net, which -- full disclosure again -- is developed, managed, and paid for by my employer. Why Launchpad? Because it's convenient, I have insiders I can bug, and because it already supports hosted Bazaar branches. Let me emphasis that Canonical is in no way driving this. They don't care what we do for Mailman, and understand fully that stuff like this are community decisions. I personally think Bazaar+Launchpad will make some of our lives easier, but if you guys do not agree, we'll stick with what we've got, no harm, no foul. Please do share your opinions freely here in public, or via private email. Cheers, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRjkMDHEjvBPtnXfVAQLcXgP/fnriiMwu9gAQEvXmUiGLXLSfkcmkzyAm cqbu2QjmTm7uZapFq3WLmItfBuoVP3HkOdaa+ibpgR8WJUxt6UksbFXCSPPxmWlR tPI8BS65r0gnf0MUM3dvbvkhizGVmYkhK7gAW6dmH43Um1o5CbskkbaWjIMLJ+0L ter/gGwLu+8= =ftG9 -----END PGP SIGNATURE-----

14 48

Re: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman: [8210] branches/modernize_21_webui/mailman/devel/ run-server.py
by Barry Warsaw 08 May '07

08 May '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 8, 2007, at 3:06 PM, akuchling(a)users.sourceforge.net wrote: > Revision: 8210 > http://svn.sourceforge.net/mailman/?rev=8210&view=rev > Author: akuchling > Date: 2007-05-08 12:06:28 -0700 (Tue, 08 May 2007) > > Log Message: > ----------- > Add a little web server script Cute! - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRkDM13EjvBPtnXfVAQLDSAP8DS8qQLT9dVw+YaF1puC40o5Q8rM5a1AD sVFwADCT0VIc9C+SABjre38Lu7ZdKphILDUgCLMEusBJrbEuH7slpFJsVOQp0CQK Z/E8/Xu362wOaExgSqEMGH60rroFCadP7CDYKORCUNMLQ2Z8BNq33LsIPRnvR2L6 1hVApHgw+gU= =wvPM -----END PGP SIGNATURE-----

1 0

Templating the interface
by Aaron Crosman 05 May '07

05 May '07

Since Barry suggested that conversation about improving the mailman GUI should be moved here, I thought I'd take a minute to ask a couple starter questions. First, let me say, that I'm willing to do some of the work on this part of the project. In the organization I work for (and run mailman for) the biggest complaints I hear revolve around the interface, and the lack of control over the design, so I'd love to see a proper template system in place. That said, I'm not clear where this project stands. I've been reviewed the summary from last summer's SoC work, and while that's given me some idea of what was done, I don't have a good sense of how and where to get started on helping. Can you all offer some suggestions about what I can do to be helpful and contribute? Aaron

12 24

status of backscatter prevention?
by Jo Rhett 04 May '07

04 May '07

I remember a number of threads about backscatter prevention, but I don't remember the result. Perusing the archives isn't much more enlightening. Where are we on this? In particular, other than removing all but one of the aliases, have we made it easier for people to run a backscatter proof list? Meaning that all subscribe, unsubscribe, etc are done on the web ui and nothing in the server automatically responds to e-mail other than legitimate list mail sent by subscribers? I also remember discussions about honoring SpamAssassin headers to detect spam. Status of this? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness

1 0

Developing for mailman is hard
by Ethan Fremen 04 May '07

04 May '07

Hi! I'm a spoiled young brat who used to have ambitions to be a graphic designer, did a couple of underground 'zines right around when this whole "web" thing started. Anyway, so I got dragged kicking and screaming into the programming side of things- astute googling would find some posts of me complaining that there's no good GUI for Apache. What drew me to mailman back in the mid 90's was the fact that it had a nice web interface, so I have always thought of mailman as a web app that happens to handle message processing. Client side web development is really kind of dreamy; you edit the file, upload it to the server, see what's changed, lather rinse repeat. PHP doesn't stray far from this model; most PHP "apps" are "drop this folder into your DOCHOME and give it DB privs" to set up. Usually, developing for these apps can be done right from a checkout, or at the very least once the build process is complete there aren't any dependencies on it. I can find no way to get anywhere close to this model in trying to improve the web UI. To be clear, my ignorance of make, ant, and all that is pretty much nonexistent, so I'm hoping my most crucial problems are merely on account of that ignorance. * running instance -> checkout issues. I want to make changes to mailman python objects and get those changes back into a checkin. The closest I came to a working approach was: 1.) build mailman. 2.) fiddle settings so that the web UI doesn't interfere with other mailman install. 3.) remove the Mailman directory and symlink the Mailman directory from the repository. This more or less works, but any time I want to add, rename or delete anything I have to fix all the makefile stuff in order for the branch to be buildable. I also can't re-run the build process without repeating the delete/symlink dance. (also, the HTTPserver has to be restarted on each change... i vaguely fixed that on my branch, but I have no idea if that made it in elsewhere). This will partially be mitigated if we move to a distributed source code model, because I can just maintain all the utterly gerfucked branches I need to and I won't be cluttering other people's revision logs with all sorts of SVN modifications. How do you "round trip" between a test instance and source code? * Templates bult on compile. I want to make changes to the templates and then make sure they build properly in all languages, I have the right i18n strings, etc. The UI templates seem to be built during compile time; while there is vast consensus that pre-building templates should change, is there any way to just rebuild templates from the command line? There are a bunch of other itches I have, but this is the one that makes scratching most difficult for me at the moment. Thanks for listening ;) ~ethan

1 0

Starting a CSS wiki page
by A.M. Kuchling 03 May '07

03 May '07

I've started a page with random notes about adding CSS: http://wiki.list.org/display/DEV/StyledPages Edit away! Given my interest in the archiver, I'm starting by looking at the archive templates and noting some ideas for what should be added. --amk

1 0