[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#933: Pine wants to post my email reply, and other problems



Dale Scheetz writes ("Bug#933: Pine wants to post my email reply, and other problems"):
...
> No! It spoke to the cut off portion of my reply about keeping bug reports
> to one issue. From the rest of this post I can only assume that you are
> >from  the same school, but I will try to speak to each of your varried
> points, if I can...

Well, we have a choice here.  We can either have n zillion threads,
one about each separate issue, flooding the mailing list, or we can
have one thread of messages, and use our brians to distinguish what
we're talking about.

With respect to bugs being open or closed, it is quite easy IME to
leave a report which mentions several bugs open until they're all
resolved, and then to close it.

If you would like to turn this into n separate bug reports and deal
with them individually feel free, but I don't know what the other list
members will think ...

> On Sun, 18 Feb 1996 richard@uk.geeks.org wrote:
> > >I can do nothing functional about either of these issues.
> >
> > As to the issue of Pine's attempts to post email, I should have
> > thought that the correct action (in the absence of any wish to try and
> > fix it directly) would be to report the problem to the upstream
> > maintainers.
>
> As Ian pointed out in one of his posts (maybe private) communication with
> the upstream developer on this idea has been rejected in the past. I see
> no purpose in this book work.

There is a purpose.  The bug will stay on our bug reports page as
`forwarded to the upstream maintainer', which will alert people to its
existence and perhaps persuade them to write a patch.  I might even
find time to do it myself.  Writing to the upstream maintainers again
may change their minds.

...
> Well, in fact, Ian fails to point out that when pine exhibits this
> behavior, its default response to the question is NO (don't post this to
> the news group) which is exactly what you two are saying it should do!
> The fact that it offers to do this for you, but will not unless
> specifically asked, seems to fit the broad mix of desires of the user
> base for this program.

It is an observed fact that many Pine users post private email because
Pine gave them an impression that they were reading a news posting (by
offering to post their reply), or because they thought (because Pine
offered to) that posting their reply was accepted and normal practice.

This happens regularly to non-sensitive email, and I've seen it happen
with sensitive email in alt.sex.<potentially-embarrassing-group>.

The problem should be fixed.

>   As to the configuration problems using pine with
> INN, I can not speak to these. I use a news reader, don't use INN, and
> have no problems with either.

Err, huh ?  Are you claiming that there is no bug here, or that you
can't reproduce it ?

...
> > As to the NNTP problems: AFAICT the inewsinn package's postinst places
> > the name of the news server in /etc/news/server.  Pine's postinst
> > should either look there or, should there be no such file, it should
> > ask for a value to put there.  Having established a sensible value it
> > should insert it into the global Pine configuration file in the right
> > place.
>
> This all sounds to me like a job for the sysadmin type, not the package
> maintainer. These are all, variable and complex interaction issues that
> should not be dictated by the package maintainer!

No, this is perfectly straightforward, and there is an established
scheme for handling it.  It doesn't appear to have been documented
very well in project/standards but I do remember discussing it on
debian-devel, and the Guidelines do say:

    Packages should try to minimise the amount of prompting they need to
 do, and they should ensure that the user will only every be asked each
 question once.  This means that packages should try to use appropriate
 shared configuration files (such as `/etc/papersize' and
 `/etc/news/server'), rather than each prompting for their own list of
 ^^^^^^^^^^^^^^^^^^
 required pieces of information.

> > This much is certainly nothing whatsoever to do with INN; rather, it
> > is a serious functional bug in the Debian Pine package.  Looking at
> > the postinst for 3.91-3 (which may be out of date) I can find no
> > attemt to determine a sane value for the NNTP server.
> >
> The package maintainer takes the position that this is not his job. In
> fact, I'm not even sure this is the job of the sysadmin. Choice of an
> NNTP server is intended to be left up to the end user! That's why it's on
> the config menu.

No, choice of a (default) NNTP server should be done once for every
piece of application software on the system.  If the user wants to
change this they can set NNTPSERVER or modify the configuration for
the particular program(s).

...
> Well, many messages in pine act this way. If ispell is not properly
> configured for pine the error message can only be seen by holding down
> ^T. This is far afield of the reported bug under discussion, but if you
> wish to report it as a bug, I will pass it allong to the upstream
> developers and see what thy say. Please make the report clear, to the
> point, and one topic only.

If you're having trouble administering these bug reports I'll be happy
to do this.  I presume that you do agree that it is a bug ?

> > This much is also nothing to do with INN.
> >
> > The dodgy Path: line is (AFAIK) not something which will break posting
> > in and of itself - indeed, if Ian is getting to see it at all then he
> > must have made a posting successfully - but is certainly something
> > that ought not to be there, and if it is established that Pine is
> > inventing a bogus Path: line then this, too, should be reported to the
> > upstream maintainers.  As Ian says, it's not really Pine's job to do
> > this.
>
> At this point, with such sketchy info, it's not clear when or if it is
> pine's job or if pine is in fact doing it, or if pine can be made to not
> do it. This still looks to me like a config problem, but with more
> specific information I can follow the trail and see what needs to be
> configured to stop the offending behaviour, although this is low priority
> for me.

What specific information would you like ?

> > One of the problems with USENET is that the written documentation is
> > widely scattered when it exists at all; one has to go by the de facto
> > standard of what other software does.  This makes it hard to argue
> > about the `right' way to do things.

On the other hand, it means that it is usually right to defer to
people who've had more experience than you or have been around longer.

...
> > [1] OK, I'm a bit prejudiced as I don't actually like the Pine user
> >     interface.  If anyone wants to argue the pros and cons of Pine as
> >     a mailer with me then they are invited to do so by private email
> >     rather than debian-*.
> >
>
> It is this that I have found so frustrating about dealing with you two
> about this bug (and some others). Ian has admitted to me in private
> communication that he isn't even a Pine user! Now, after wading through
> your rather long winded, diversionary discussion, I discover that very
> likely you don't use the product either!

Several of the bugs we've reported affect the correspondents of those
who use Pine.  For example, when I asked Bill Mitchell to send me a
uuencoded file he fairly naturally hit `attach' in Pine, which
promptly base64-encoded his uuencoded file.  This bug in Debian's Pine
affected me as a non-Pine user.  The bug which causes/encourages
private email to be posted in the quoted text of a reply usually ends
up posting the private email of a trn or Emacs user, not that of a
Pine user.

One of the things that's so frustrating about trying to get Pine's
numerous interoperability bugs fixed is that they work fine with other
copies of Pine.

Furthermore, I'm not a non-user of Pine.  I use it occasionally,
usually when I need to decode a file that some Pine user has sent me
by mistake (theirs or Pine's).

> I am quite happy to work with users of this package to make improvements
> where possible. I am quite fed up with dealing with non-users over issues
> that the developer and I agree are non-bugs! When I have the time, I will
> close this bug and any future openings of the same bug with a copy of
> this posting.

I'd like you to reconsider this.  Furthermore, I'm not clear on which
issues you think are not bugs ?  Should I go back to my original
report and resend each issue as a separate report ?

> Thank you for your time,

Thank you for yours.

Ian.


Reply to: