"Kevin" == Kevin McCann kmccann@cruciverb.com writes:
[about project management]
Kevin> - The Mailman project is not as open as it could be. There
Kevin> is too much control over who can contribute code, how they
Kevin> can do it, when they can do it. I understand wanting to
Kevin> maintain quality and stability, but effort and goodwill are
Kevin> going to waste.The code is open source, easily available in public, and with the exception of security bugs planning is done on public channels. The project is as open as it needs to be to enable progress.
OTOH, since running Mailman (like any network application) is a security risk, I _want_ to see firm controls over who can commit to the codebase _I_ install from. Those of you who _need_ to get to the bottom of the cliff in sqrt(2*s/g) seconds should jump, of course. But I'm taking the tram.<wink>
Kevin> But the projects need to be able to move forward,
Kevin> unencumbered by control and competing
Kevin> commitments. Otherwise nobody will fund it.There is no "control"; the code base is open source. What you want to do by getting the MM cabal to do and/or distribute the work is to leverage the _trust_ MM users have in the project leaders, and the _access to beta testers_ that the project gets in return. That's a valid way to proceed, but to get that leverage you need to help the developers maintain the trust by giving them accurate specifications to work from.
Kevin> are developers willing to have MM3 be a new,
Kevin> different, separate beast than MM2?The MM3 prototype code is new from the ground up. The MM2.0->MM2.1 transition was a remarkably radical refactoring, plus a huge effort for internationalization, for all that upgrading was trivial for most people. I'd bet on trying to work with the current developers rather than forking---they have a history of doing radical stuff and succeeding.
[about why current leadership has not produced the feature]
Kevin> - Not everyone sees the need for a highly integratable
Kevin> MLM,Of course the developers see it. They've paid plenty of lip service, and even incorporated some code. I don't feel like they're disingenuous, though. I think they personally don't need it, and people who _articulate the requirements_ (rather than "beg for the 'feature'") are lacking.
So it's very difficult for them to specify the requirements. They've tried: MemberAdapter was supposed to enable integration of databases for membership management. But it evidently didn't work very well, and it doesn't seem to have gotten a very enthusiastic reception. John Dennis has been pushing that line forward, but I don't get the impression that he is getting tons of good input on the requirements. Instead, he posts here asking the same leadership that didn't really know what the requirements were the first time what they think the requirements might be!
On the other hand, the ad hoc DB integration ideas I've seen discussed to date all have a very strong "works for me" flavor to them. Ie, "if you want something generalizable, then MM people will have to do that, but here's a proof of concept."
Kevin> despite the fact that people have been begging for it for
Kevin> half a decade. They beg for it on the Mailman list. They
Kevin> beg for it on the Sympa list.Beg, build, or buy. Plan A has failed. Try Plan B or Plan C.
My suggestion is Plan B, because Plan C probably requires a fork (as you mention, Barry is committed elsewhere). If I needed what you need, instead of posting the call for discussion _here_, I would post on *Mailman-Users*:
(1) summarize the current facilities (like MemberAdapter, however weak they may be),
(2) find out what John Dennis has been up to and what ad hoc patches have been submitted, and summarize their interfaces (not the implementations!),
(3) find out what the objections to the methods described in (1) and (2) are, both from would-be users and from the leading developers, and summarize them.
Those summaries, plus response from potential users, will be the foundation to work forward from there to (a) specifications and (b) designs. Actual prototype code would be groovy, of course, but the current developers (and 3rd parties? I think John is a 3rd party?) have already shown willingness to write at least some code.
Once you've got that, you can bring it back here. (Python-dev people will recognize this---including the recommendation to ask users, not developers, about the requirements---as an informal version of the PEP process. It works.)
And if in fact you're right, the MM developers don't care, and snub you ... you've lost nothing! You've got the spec you need to attract both developers and backing (including funding)---and the MM2.1 code base to start from.
-- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.