On Mon, Apr 02, 2012 at 08:04:23PM -0700, David Jeske wrote:
On Apr 2, 2012 3:07 PM, Terri Oda te...@zone12.com wrote:
This agrees with my view of the situation as well. Which leads to the
question, is the above approach interesting/viable for Mailman-team?
(assuming the code does something
I think it would be a mistake to bundle any archiver with mailman3.
Listing the available archiver options and their features and
shortcomings would be a better way to go.
-1
I think the majority of MM users will be simply using the RPM that comes with
their distro, and there is a real
On Apr 3, 2012 8:14 PM, Bob Puff b...@nleaudio.com wrote:
I think it would be a mistake to bundle any archiver with mailman3.
Listing the available archiver options and their features and
shortcomings would be a better way to go.
-1
I think the majority of MM users will be simply using
On Apr 3, 2012 11:58 AM, Toshio Kuratomi a.bad...@gmail.com wrote:
The question is would you BUNDLE another archiver even if the licenses
don't match?
Where could your archiver fit into that sequence of impressions? I'm not
entirely sure. I think that it probably couldn't be bundled into
On Wed, Apr 4, 2012 at 1:16 PM, David Jeske dav...@gmail.com wrote:
On Apr 3, 2012 8:14 PM, Bob Puff b...@nleaudio.com wrote:
I think the majority of MM users will be simply using the RPM that comes with
their distro, and there is a real benefit to stuff working right out of the
box. This
On Wed, Apr 4, 2012 at 3:58 AM, Toshio Kuratomi a.bad...@gmail.com wrote:
From the talk about what it means to be a FSF project at the mailman sprint
at pycon I don't think a non-FSF copyright assigned archiver would be
bundled into mailman (Core).
AFAIK there are no FSF projects, although
