[Mailman-Developers] Informal "MEP" process, anyone? [was: PHP Wrappers?]

Stephen J. Turnbull stephen at xemacs.org
Thu Nov 17 06:19:05 CET 2005


>>>>> "Kevin" == Kevin McCann <kmccann at 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.


More information about the Mailman-Developers mailing list