[Mailman-Developers] Re: Future of pipermail?

[Barry A. Warsaw]

>>>>> "CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:

    CVR> excuse me if I quietly twich at the terminology (does anyone
    CVR> know where this -ista stuff came from? My first run-in iwth
    CVR> it was Guy Kawasaki and his "evangelistas", but was it used
    CVR> before that?

Dunno, and I'm not sure who invented "Pythonista" or "Perlie" or
whatever.  I actually like the term "Pythoneer" because it's
reminiscent of "Pioneer" and "Engineer".  Maybe we should just call
them "Bruces" (to avoid confusion :).

    CVR> I'm starting to see serious pushes (and I'll self-admit to be
    CVR> one here!) towards serious, hard-core integration of
    CVR> technologies. Which is a double-edged sword of the worst and
    CVR> best kind.

I think the trick is to balance what is necessary and expedient for
Mailman with long term flexibility and integration with standards.
Given the size of the todo list, where we can leverage existing
technology we probably want opt that way instead of inventing our
own.  But the flexibility is important because different sites have so
many different requirements.

That's why I like the idea of moving toward a core set of classes and
scripts that provide the basic Mailman functionality, building
interfaces and hooks so that people can do the customization they
want.
    
    CVR> There's HUGE synergy potential here. We certainly shouldn't
    CVR> avoid those things, but the more we start tying into (and/or
    CVR> depending on) other technologies, the more we lock users into
    CVR> a single technology suite, the more we start depending on
    CVR> specific technology suites the more we lock uers into our
    CVR> view of how things work, and the less flexibility we give
    CVR> them in building their sites. And, to some degree, the less
    CVR> ability we have to adapt to future changes in the net
    CVR> universe ourselves.

    CVR> None of which is a reason to not do these things -- but it's
    CVR> reason to be wary. We really need to understand how these
    CVR> things interact and what the side effects are, including
    CVR> things as basic as "does this mean it'll never run on Windows
    CVR> NT again?" or "did we just set it up so they have to run
    CVR> apache?"

I agree.

    CVR> WebDAV looks fascinating. WebDAV -- as mailman's default
    CVR> archiver -- looks to me to be overkill at a quick
    CVR> evaluation. Yes, it'll be in there by default for apache 2.0,
    CVR> once Apache 2.0 ships and is out for a while and everyone
    CVR> upgrades. that's, what, 2 years out before 50% of the sites
    CVR> are running apache 2.x? Easily. Until then, what do we do?
    CVR> And what about non-apache sites? what's this do to mailman
    CVR> across all supported platforms?

    CVR> I dunno -- but there's a lot of complexity here we need to
    CVR> make sure we deal with in these issues. And to some degree, I
    CVR> think it's another excuse for me to pull out the "lots of
    CVR> separately tracked modules with API's" schtick, because we
    CVR> can build a Mailman API and a WebDAV plug-in for it(along
    CVR> with Mhonarc and Pipermail plug-ins) and over time, as WebDAV
    CVR> becomes endemic, switch the priority of development in its
    CVR> direction, without locking into it. In two years, there'll be
    CVR> other stuff beyond WebDAV, too, I'll bet.

Agreed again.

    CVR> I know, I know... it's all details. Details are boring
    CVR> (grin). but necessary...

Indeed.  There's also the "worse is better" mantra, or put in other
words: "All software sucks, let's just try to suck less". :)

-Barry