See what happens when you go on vacation? So many interesting issues to untangle! I'll try to catch up but my responses will no doubt be somewhat fractured.
First of all, thanks David for bringing ClearSilver to our attention and offering it to the Mailman project. We can all agree that Pipermail is dated, is missing key features, and needs to be replaced. It's been removed from the lp:mailman branch. What does it mean to be part of the "GNU Mailman" project? This used to be an easy question to answer because everything was bundled. When you download the mm2.1 tarball, you get an archiver, a web ui, and an engine. Everything is GPLv2+'d with copyright owned by the FSF. Life is simple. Now we have at least two separate subprojects, the core and the web ui. It's very likely that what we'll call "GNU Mailman 3.0" will be just the core. For various reasons, this needs to be released as soon as possible, but it's important to understand that it won't be a full replacement for Mailman 2.1. I think of it more like the Python 3.0 release - a critical milestone for the project, usable on its own, but with deficiencies we both know about and don't yet know. We'll need to manage expectations, but it's also true that it just will not get a full workout until it's got that "final" stamp on it. We can't wait for Postorius or an official archiver, but both those will probably be included in future releases. One of the core principles of mm3 is that site admins get more choices. You can use Postorius as your web ui, but it's also easy to use something else, or no web ui at all. Want to use your own archiver? No problem. Want to throw all your data into PostgreSQL and drive the user database off your corporate databa$e? No problem (hopefully :). So again, in a mm3 world, what does it mean to be part of the GNU Mailman project? Here are some of my own principles, and I'd like to hear yours. No fiefdoms in the code. I much prefer projects where everyone feels a shared sense of stewardship for the code base. Of course we'll have experts in one area or another, and everyone is going to have an opinion about how things should work. Hopefully you won't depose me as BDFL just yet. But I do think that nobody should have veto power over any particular aspect of the code. An expert, or even myself, should be able to make a convincing technical argument for why something should be done or not done, and that should hold sway over a collective solution. Now, it might be because one way is the right way to do it, or because another way is the expedient way. And not everyone will agree with every decision, but I also think it's important to fight the good fight and then work hard to make this a successful collaboration. Of course, you're never forced to hack on something you disagree with. Almost above all else, this should be *fun* :). This relates to big code donations like the archiver. Once we as the Mailman project accept something under our umbrella, we all have the right and responsibility to dig in and hack on it. In Python, I don't think it's really worked out very well to have some big donated module be "owned" by one person. There are both pros and cons for getting subsumed into a project, so only do it when everyone understand and agrees to that. As I mentioned, bundling and releasing was easy in 2.1. It'll be easy in 3.0 only because that will probably just include the core. What does a release look like in Mailman 3.1 and beyond? How do we take all these disparate projects (Postorius, the API client, an archiver, etc.) and release these in an easy to download and install format? I'm still not sure, and I'm not holding up the 3.0 release to figure that out, but we will have to figure that out at some point (and probably get it wrong the first few times :). Licensing was also an easy decision. Everything was GPLv2+. Now the core is GPLv3+, as is Postorius. I'm not a licensing zealot; I'm pretty much happy to hack on anything that has a FLOSS license. I think a copyleft Python would fail miserably, but copyleft has worked well for Mailman for probably 15 years, and it's too late to change the license. I'm happy for people to make money off of Mailman, but the GPL helps ensure and encourage that folks give back to the project. GPLv3+ seems right for the core, and pretty right for the web ui (AGPL might be better, but Toshio has identified some problems in practice with it). I would certainly prefer that any archiver that gets bundled under the GNU Mailman moniker be copyleft, with copyright assigned to the FSF. The core and web-ui are already structured this way, so I think the consistency ultimately makes our lives, and more importantly the lives of our users, easier. Those are my preferences anyway. Maybe copyright assignment to the FSF isn't right for the archiver, but I need a more convincing argument than "I don't like it". Same for choice of license. From a project management perspective, consistency is a big win, so convince us why it's better, or at least okay, to have different licensing and ownership regimes under a single project's banner. Oh, one more principle I'd like to maintain: please write it in Python. No disrespect to other languages, but Python is just more fun and consistency counts. Okay, okay, you can include some JavaScript for the web bling if you must. :) Cheers, -Barry
signature.asc
Description: PGP signature
_______________________________________________ Mailman-Developers mailing list [email protected] http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
