[Mailman-Users] Mailman archive messages(not rm, but install!)

[Stephen J. Turnbull]

Brad Knowles writes:

 > The problem is that the conversation I had with Alan up to that point 
 > had lead me to believe that we were talking about a standard Mailman 
 > installation as provided in package format by Debian, and yet Alan's 
 > configuration clearly lacked what I consider to be a pretty important 
 > core component.

Right.  And because of the way that Debian handles complex packages
(Mailman qualifies, barely), it's quite possible that that would occur
as a bug.

 > We need to go further and tell them that this *may* be a packaging 
 > issue, and that they need to consult with their administrator or 
 > their vendor, or whomever actually installed the software or is 
 > responsible for administering the software and/or hardware, to 
 > confirm whether or not this actually is a standard version installed 
 > from a package somewhere, or if this has been customized by someone. 

Well, pedantically you're right.  So, if the person is on a system
that supports locate, tell them to "locate pipermail.py".  If it
doesn't show up or is in a bizarre place, send them to the distro.
But my experience with XEmacs is that 95% complaints about missing
components that appear to be packaging problems *are* packaging
problems.[1] So I took the shortcut of saying "bounce it to Debian."

 > But someone needs to find a simpler way to explain this.

I don't think it's possible.  Someone who uses a distro, discovers the
package is missing functionality, and reports to Mailman first has a
clue loose.  That's no sin, but it does imply that they're likely to
need hand holding to even understand why it's hardly likely to be a
Mailman issue.

 > I still don't feel that we should be responsible for reporting bugs 
 > to all the hundreds or thousands of distributions, open source OSes, 
 > commercial OSes, etc....

Not all the bugs.  Most bugs are the users' place to report.  But
reports of packaging bugs where it's a matter of judgment as to what a
minimal package includes, or what features should be in by default,
are best informed by the kind of experience the developers have.  As I
wrote, my opinion is informed by great responsiveness from several
distros, with respect to XEmacs.  And the kind of bug that justifies
direct attention from the upstream maintainer/support (rather than
telling the user to report to the distro) is not that frequent.

N.B.  This is very similar to what's being discussed on python-dev
regarding Python project input into the Linux Standard Base.  Clearly
the consensus there is that they should provide some input (though
they haven't decided what the content should be yet).

Also, in my experience on both sides of the dialog, upstream
maintainers are likely to get more attention from downstream than
downstream's ordinary users are.

 > We are not the user of the Debian software in question.  We should 
 > not be required to report what we consider to be bugs through their 
 > tracking system.

Not *required*, but if a report *from* us prevents 10 reports *to* us,
maybe that's a worthwhile tradeoff.

 > that's also a two-way street -- if they're taking our code and making 
 > any modifications to it, then they should be feeding those back to us.

Functionality, yes.  Packaging?  I think not.  But most changes (by
Debian, at least) are for integration into a specific environment, not
actually fixes or enhancements.  It's unfortunate, but not surprising,
that sometimes distros get a little lazy about reporting to upstream.

Footnotes: 
[1]  In XEmacs's case, they're often *our* bugs.  But Mailman's only
distribution has batteries included; missing functionality is not a
Mailman bug.