RE: emacs 21.2

RE: emacs 21.2

[Marshall, Simon]

I realise that Emacs releases have changed, and odd-numbered releases
are different in some way to even-numbered releases, but could someone
explain what the difference is meant to be?

Many of the problems I raised since the last pretest (AFAIK 21.1.90,
almost 2 months ago), which (AFAIK) were fixed when reported, are not
fixed in 21.2.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: emacs 21.2

[Eli Zaretskii]

> From: "Marshall, Simon" <simon.marshall@misys.com>
> Date: Fri, 22 Mar 2002 09:40:59 -0000
> 
> I realise that Emacs releases have changed, and odd-numbered releases
> are different in some way to even-numbered releases, but could someone
> explain what the difference is meant to be?

There's no such rule; odd-numbered releases are not special.

What actually happens is that the bug-fix releases, such as 21.2, are
produced from a CVS branch, while development continues on the trunk.
Changes committed on the trunk alone won't be seen in the releases
produced from the branch.  If we decide that there should be another
bugfix release, it will be labeled 21.3, but will still be produced
from the release branch.

This didn't start with Emacs 21, btw: Emacs 20.6 and 20.7 were also
produced from a branch (except that in that case, ``the branch'' was
a separate directory rather than a VC branch).

> Many of the problems I raised since the last pretest (AFAIK 21.1.90,
> almost 2 months ago), which (AFAIK) were fixed when reported, are not
> fixed in 21.2.

As a matter of principle, the release branch only gets safe bugfixes,
so it's possible that some of the changes are not there if they were
deemed unsafe, or if the bugs were deemed not grave enough to risk a
change.  It is also possible that we forgot to commit the changes to
the branch, so please tell what changes, specifically, do you have in
mind.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

RE: emacs 21.2

[Marshall, Simon]

> > Many of the problems I raised since the last pretest (AFAIK 21.1.90,
> > almost 2 months ago), which (AFAIK) were fixed when reported, are
not
> > fixed in 21.2.
> 
> As a matter of principle, the release branch only gets safe bugfixes,
> so it's possible that some of the changes are not there if they were
> deemed unsafe, or if the bugs were deemed not grave enough to risk a
> change.  It is also possible that we forgot to commit the changes to
> the branch, so please tell what changes, specifically, do you have in
> mind.

I appreciate "safe" is a valid criteria, and "grave" is of course
subjective.  These I imediately noticed were not fixed in 21.2.

- Emacs/LessTif scrolling
- the menu-bar-update-hook problems

The first means Emacs scrollbar scrolling is awful, for large buffers
and at the end of any buffer larger than window height, bad enough to
force me to use other means of scrolling.  The second makes Emacs
unusable when Imenu is enabled in many situations.  Even the imenu.el
changes didn't go into 21.2.  

I realise each bug is a difficult call.  But to explain my perspective,
if I had known that none of the above had been fixed in 21.2, I would
not have (a) upgraded and (b) bothered using the pretest versions.  I
can see me following the same perspective for future pretests for 21.3.

Simon.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: emacs 21.2

[Eli Zaretskii]

> From: "Marshall, Simon" <simon.marshall@misys.com>
> Date: Fri, 22 Mar 2002 12:43:42 -0000
> 
> I realise each bug is a difficult call.  But to explain my perspective,
> if I had known that none of the above had been fixed in 21.2, I would
> not have (a) upgraded and (b) bothered using the pretest versions.  I
> can see me following the same perspective for future pretests for 21.3.

I'm sorry to hear that.  From the v21.2 pretest experience, it sounds
like the interest in trying the pretest versions has diminished lately
in general.  If that is so, the adverse effects of that will certainly
show in the long run in the quality of our releases.  I lament that
tendency, and hope I'm dead wrong in my conclusions.

I wish people would understand that sometimes stability is more
important than fixing some annoying misbehavior or adding new
features.  I wish more people who read this list would participate in
pretesting Emacs, even if the release under pretest is a minor bugfix.

Of course, since there's a judgement call involved, everybody is
welcome to step forward and argue for the changes they think should
be included.  But if you don't speak up, I can't see how can we take
your views into account.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

RE: emacs 21.2

[Marshall, Simon]

> I'm sorry to hear that.  From the v21.2 pretest experience, it sounds
> like the interest in trying the pretest versions has diminished lately
> in general.  If that is so, the adverse effects of that will certainly
> show in the long run in the quality of our releases.  I lament that
> tendency, and hope I'm dead wrong in my conclusions.
> 
> I wish people would understand that sometimes stability is more
> important than fixing some annoying misbehavior or adding new
> features.  I wish more people who read this list would participate in
> pretesting Emacs, even if the release under pretest is a minor bugfix.

I don't know if you meant to direct this comment at the emacs-devel list
only; I changed the recipients from emacs-pretesters when I brought this
up since I originally just wanted to understand the release policy.

If it was directed at pretesters, then, put yourself in my (a pretester)
shoes.  I spent a large amount of my own time tracking down problems
with the last pretest & coming up with some fixes & testing others'.  I
did it because I thought it would be worth it: I thought the next Emacs
release would fix those problems.  Why would I bother if fixes wouldn't
appear in the next release?  Why would I bother if I could just leave it
to the pretests after next (or some future) release?

> Of course, since there's a judgement call involved, everybody is
> welcome to step forward and argue for the changes they think should
> be included.  But if you don't speak up, I can't see how can we take
> your views into account.

I think it is difficult for pretesters to follow the release policy
(assuming that they know what it is---I didn't/don't) and make these
kinds of judgements.  I think it has to come down to the judgement of
you guys.

I think your release policy itself is wrong---assuming I know what it
is---I think the only reason to release a version that does not fix
serious but not necessarily fatal bugs is when a quick release is needed
because the previous release was broken.  I think 21.2 should have fixed
known serious bugs as well as addressed "stability" (however you define
that) issues.

To take your 2nd para above, you say "even if the release under pretest
is a minor bugfix".  What on Earth does this mean?  IMHO, and no
criticism should be taken by anyone at all, it had some serious
behaviour and performance bugs.  Are you saying that, from the
beginning, only minor fixes would be going in 21.2?  What was the point
of that?

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: emacs 21.2

[Juanma Barranquero]

Sorry for jumping in.

On Fri, 22 Mar 2002 15:20:32 -0000, "Marshall, Simon"
<simon.marshall@misys.com> wrote:

> If it was directed at pretesters, then, put yourself in my (a pretester)
> shoes.  I spent a large amount of my own time tracking down problems
> with the last pretest & coming up with some fixes & testing others'.  I
> did it because I thought it would be worth it: I thought the next Emacs
> release would fix those problems.  Why would I bother if fixes wouldn't
> appear in the next release?  Why would I bother if I could just leave it
> to the pretests after next (or some future) release?

If I understand you right, you're saying that you consider pretesting
valuable for you if it is going to help to solve ASAP the problems you
encounter/suffer.

Well, I certainly don't see it that way. To me being a pretester is more
like voluntarily giving a helping hand in ironing out the bugs of Emacs
in a general way. Whether any fixes are to be included in the next
release, or the next one after that, or perhaps deemed too difficult, or
not right, or whatever, is not my call to judge. Obviously I would
"fight" and argument if I was told that something I deem very important
is to be delayed... but I ultimately must trust those who have more
Emacs experience than I do. And I'm not talking just about technical
experience, but project management experience as well.

> I think your release policy itself is wrong---assuming I know what it
> is---I think the only reason to release a version that does not fix
> serious but not necessarily fatal bugs is when a quick release is needed
> because the previous release was broken.  I think 21.2 should have fixed
> known serious bugs as well as addressed "stability" (however you define
> that) issues.

src/ChangeLog contains 367 non-blank, non-header lines of log comments between
release 21.1 and 21.2. lisp/ChangeLog has 329. Not earthshaking, but
nothing "minor" about it.

IMHO, increasing stability without simultaneously increasing complexity
for the users who want to use Emacs without it changing a lot under
their feet is a good, sensible goal.

But I don't think Eli is saying that 21.2 was meant to be a "minor
bugfix" under any circunstances; more like "it is a necesary release even
if only has minor bugfixes". The point not being "serious bugfixes won't
go in", but "no unnecesary changes (of interface, new features, etc.)
will go in". If a bug needs a big fix, it probably does not increase
stability...

That's not to say that a single, serious bug wouldn't be reason enough
to release a version, though :)

All that's MHO and nothing more, of course :)

                                                           /L/e/k/t/u


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: emacs 21.2

[Stefan Monnier]

[ Do you read your simon@gnu.org email ? ]

> - Emacs/LessTif scrolling

This has been installed on the branch and then removed (and simon@gnu.org
was cc'd when those things happened, IIRC).  The reason was that it was
too late, didn't get any testing apart from yours and wasn't considered
a serious enough bug.


	Stefan


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

RE: emacs 21.2

[Marshall, Simon]

> [ Do you read your simon@gnu.org email ? ]

I will when I finally get over ssh problems.

> > - Emacs/LessTif scrolling
> 
> This has been installed on the branch and then removed (and 
> simon@gnu.org
> was cc'd when those things happened, IIRC).  The reason was 
> that it was
> too late, didn't get any testing apart from yours and wasn't 
> considered
> a serious enough bug.

Well, "too late" depends on what is the highest priority: to fix a bug
or to make a particular release date.  But I take your point.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

RE: emacs 21.2

[Marshall, Simon]

> If I understand you right, you're saying that you consider pretesting
> valuable for you if it is going to help to solve ASAP the problems you
> encounter/suffer.

Not quite.  Pretesting is worthwhile (for me)
right-now-this-moment-as-I-speak if the effort I put in will result in
fixes in the next release.  If the effort will not result in fixes, I
would be tempted to put it off until I think it will.  After all, if my
effort will not make a difference to any user (including me) until 21.3
or later, I'm thinking why bother putting that effort in for 21.2?  It
won't make any difference to anyone and it's not like I have time to
burn.

So, I thought my effort would be worthwhile for 21.2, but it turns out I
was wasting my time and I could've left it "until later" without it
making any difference to Emacs for users (and pretesters if not
developers).  Mañana.

The other point---"ASAP".  I don't care if I don't get patches for fixes
to a pretest, though I'm happy to test them.  I don't care if the next
release with the fixes is not soon----I wouldn't be a pretester if that
was the case.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: emacs 21.2

[Eli Zaretskii]

> From: "Marshall, Simon" <simon.marshall@misys.com>
> Date: Fri, 22 Mar 2002 15:20:32 -0000
> 
> I don't know if you meant to direct this comment at the emacs-devel list
> only

It was meant to anyone who is interested in Emacs development.
emacs-devel is certainly a good place to find those people.

> If it was directed at pretesters, then, put yourself in my (a pretester)
> shoes.  I spent a large amount of my own time tracking down problems
> with the last pretest & coming up with some fixes & testing others'.

Thank you very much for those efforts.  They are certainly
appreciated.

> I did it because I thought it would be worth it: I thought the next
> Emacs release would fix those problems.  Why would I bother if fixes
> wouldn't appear in the next release?

It is not always possible to fix everything in the version currently
under a pretest.  If the bug is minor and the fix can potentially
affect other places in Emacs, then there's a judgement call whether to
fix it in the upcoming release or the one after that, especially if
the pretest is otherwise stable and ready for a release.

A pretest should be a converging process--as it proceeds, the codebase
should become more and more stable (less bugs, less crashes, etc.), at
least on the average.  Installing a change that potentially
destabilizes the code could mean either unstable release or more
pretest releases and a resultant significant delay in the release
date.  So there's a clear tradeoff here.  I'm sure I'm not telling
you anything you didn't already know.

> > Of course, since there's a judgement call involved, everybody is
> > welcome to step forward and argue for the changes they think should
> > be included.  But if you don't speak up, I can't see how can we take
> > your views into account.
> 
> I think it is difficult for pretesters to follow the release policy
> (assuming that they know what it is---I didn't/don't) and make these
> kinds of judgements.

Whatever is not clear can be explained if you ask.  The CVS, both the
release branch and the development trunk, are there for you to
scrutinize.  There are special mailing lists where you are notified
about commits to the CVS; you can subscribe to one of those lists and
monitor the changes, to know whether your patches are installed for
the next release or only on the trunk.  Failing all that, you can ask
explicitly.

In other words, the development process is open--you are welcome to
monitor the decisions and speak up your views.

> I think your release policy itself is wrong---assuming I know what it
> is---I think the only reason to release a version that does not fix
> serious but not necessarily fatal bugs is when a quick release is needed
> because the previous release was broken.

Emacs 21.1 is not broken, but it has a number of annoying redisplay
bugs, albeit subtle ones, which don't show up except in sufficiently
rare situations.  The main purpose of 21.2 was to quickly fix those
problems, in order to make Emacs 21 as good as Emacs 20.7.  Problems
which existed in Emacs 20.x, such as the scroll-bar behavior, do not
belong to this class of problems.

As to the next release, AFAIK we still need to see whether v21.2 is
stable enough to make it the last release from the branch or not.  If
it is, the next release will have all of your changes.

> To take your 2nd para above, you say "even if the release under pretest
> is a minor bugfix".

That wasn't said about Emacs 21.2.  It was a general statement.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: emacs 21.2

[Eli Zaretskii]

> From: "Marshall, Simon" <simon.marshall@misys.com>
> Date: Fri, 22 Mar 2002 17:34:13 -0000
> 
> After all, if my effort will not make a difference to any user
> (including me) until 21.3 or later, I'm thinking why bother putting
> that effort in for 21.2?

I can think about two reasons:

First, it's possible that the fix _will_ be in the next release.  It
depends on the problem you find and the change needed to fix it.

Second, even if the fix will not be in the next release, reporting the
problem immediately would allow enough time to find a good fix for it,
and to test that fix before the pretest of the next version even
starts (there are quite a few people who use the CVS head version as a
matter of routine).

By contrast, if you postpone a problem whose fix is not a trivial one
until the next pretest, there are chances it won't get into that
pretest as well.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: emacs 21.2

[Jason Rumney]

"Marshall, Simon" <simon.marshall@misys.com> writes:

> I think your release policy itself is wrong---assuming I know what it
> is---I think the only reason to release a version that does not fix
> serious but not necessarily fatal bugs is when a quick release is needed
> because the previous release was broken.  I think 21.2 should have fixed
> known serious bugs as well as addressed "stability" (however you define
> that) issues.

21.2 does fix some known serious bugs. But in each case, the chance of
the change causing its own new problems has to be balanced against the
problems it fixes. If we waited until EVERYTHING was fixed, we would
never release a version of Emacs again.

> Are you saying that, from the beginning, only minor fixes would be
> going in 21.2?  What was the point of that?

Minor fixes generally don't cause problems, they only fix them. Major
fixes come with their own set of problems.  Since 21.1 was a major
release with many new features, from the beginning it was thought that
a bugfix release would be needed.  I think more bugs were expected in
21.1 than were actually found, so perhaps that is why this release may
seem unnecessary to some people.


-- 
Jason Rumney


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: emacs 21.2

[Miles Bader]

"Marshall, Simon" <simon.marshall@misys.com> writes:
> I spent a large amount of my own time tracking down problems with the
> last pretest & coming up with some fixes & testing others'.  I did it
> because I thought it would be worth it: I thought the next Emacs
> release would fix those problems.  Why would I bother if fixes
> wouldn't appear in the next release?

If a pretest doesn't fix bug-that-annoys-you-X, which you know is fixed
in CVS, then it seems perfectly fair to bring that up as an issue with
the pretest -- as was stated earlier, many things don't get put into the
release branch simply because no one thought too, not necessarily
because they were dangerous.

On the other hand, a traditional pretest is too late for many kinds of
changes, so I wonder if it would be a good idea to officialy have two
stages in the pretest:

   (stage 1)  Did everything important get fixed?
   (stage 2)  [a more normal `no big changes' pretest]

-Miles
-- 
Suburbia: where they tear out the trees and then name streets after them.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: emacs 21.2

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Date: 23 Mar 2002 08:54:25 +0900
> 
> On the other hand, a traditional pretest is too late for many kinds of
> changes, so I wonder if it would be a good idea to officialy have two
> stages in the pretest:
> 
>    (stage 1)  Did everything important get fixed?
>    (stage 2)  [a more normal `no big changes' pretest]

Alternatively, we could announce a planned beginning of a pretest
some time, like a month, in advance, and ask the pretesters to try
the CVS code.  (A snapshot of the CVS could be prepared at that time,
if accessing the CVS is not good enough.)

In general, development on both the trunk and branch is a pain, and
also prone to errors, so it should be avoided, I think.  It's better
to have a feature freeze when the branch is cut, I think.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: emacs 21.2

[Per Abrahamsen]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> I'm sorry to hear that.  From the v21.2 pretest experience, it sounds
> like the interest in trying the pretest versions has diminished lately
> in general.

There have been 21.2 pretests?  I haven't seen any announced.  I
haven't seen 21.2 announced either, for that matter.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: emacs 21.2

[Eli Zaretskii]

> From: Per Abrahamsen <abraham@dina.kvl.dk>
> Date: Sat, 23 Mar 2002 10:03:18 +0100
> 
> There have been 21.2 pretests?  I haven't seen any announced.

The pretests were announced on emacs-pretesters.  I know that I didn't
dream, since about a dozen pretesters replied to some of those
messages.  If you read that list, but didn't see any announcements
about 21.1.x pretests, please tell me, and I will check the alias on
gnu.org.

> I haven't seen 21.2 announced either, for that matter.

It was sent to info-gnu-emacs and bug-gnu-emacs.  I've seen it in
bug-gnu-emacs, but I don't see it in the gnu.emacs.bug news group
(which probably means the gateway is hosed).

In general, there are grave problems with Emacs announcements (for
years, not just now).  They don't appear in all the places where they
should be.  We are trying to do something about that, so hopefully it
will get better for future releases.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: emacs 21.2

[Richard Stallman]

    I realise that Emacs releases have changed, and odd-numbered releases
    are different in some way to even-numbered releases, 

We do not have any general convention about odd and even numbers.

    Many of the problems I raised since the last pretest (AFAIK 21.1.90,
    almost 2 months ago), which (AFAIK) were fixed when reported, are not
    fixed in 21.2.

That is because we put only safe and simple bug fixes into 21.2.  We
make a release like this from time to time when it seems important
and the next ordinary release is some time in the future.


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: emacs 21.2

[Richard Stallman]

      I think 21.2 should have fixed
    known serious bugs as well as addressed "stability" (however you define
    that) issues.

We did try fix the known serious bugs--the question is which bugs are
"serious".

      I spent a large amount of my own time tracking down problems
    with the last pretest & coming up with some fixes & testing others'.  I
    did it because I thought it would be worth it: I thought the next Emacs
    release would fix those problems.

The next release made from the development sources will fix them.  But
we are not ready to make another release from these sources yet.
The 21.3 release will probably be made from the development sources,
but we don't know when that will be.

We made a little extra effort so we could release a 21.2 sooner
which fixes a lot of the bugs in 21.1 and has little risk of
creating any new bugs.


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: emacs 21.2

[Richard Stallman]

    There have been 21.2 pretests?  I haven't seen any announced.

We announced them to the pretesters.  You don't seem to be on the
pretest list--do you want to be?

      I
    haven't seen 21.2 announced either, for that matter.

I don't know why this announcement has not been sent through.
I will ask.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: emacs 21.2

[Eli Zaretskii]

> Date: Sun, 24 Mar 2002 08:51:46 -0700 (MST)
> From: Richard Stallman <rms@gnu.org>
> 
>       I
>     haven't seen 21.2 announced either, for that matter.
> 
> I don't know why this announcement has not been sent through.
> I will ask.

It has been sent.  I saw it in bug-gnu-emacs@gnu.org, and I approved
it for info-gnu-emacs (being its moderator).  However, the news group
gnu.emacs.bug doesn't have it, so probably the email-to-news gateway
didn't work (again).

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: emacs 21.2

[Richard Stallman]

    It has been sent.  I saw it in bug-gnu-emacs@gnu.org, and I approved
    it for info-gnu-emacs (being its moderator).  However, the news group
    gnu.emacs.bug doesn't have it, so probably the email-to-news gateway
    didn't work (again).

Does gnu.emacs.announce have it?

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: emacs 21.2

[Eli Zaretskii]

> Date: Mon, 25 Mar 2002 05:02:01 -0700 (MST)
> From: Richard Stallman <rms@gnu.org>
> 
>     It has been sent.  I saw it in bug-gnu-emacs@gnu.org, and I approved
>     it for info-gnu-emacs (being its moderator).  However, the news group
>     gnu.emacs.bug doesn't have it, so probably the email-to-news gateway
>     didn't work (again).
> 
> Does gnu.emacs.announce have it?

gnu.emacs.announce is empty (0 messages) on the news server I use.
This is a very good server (news.cis.dfn.de) which carries many GNU
groups and has very low propagation delay.  Which leads me to the
conclusion that gnu.emacs.announce didn't see any messages for a long
time.

How are announcements supposed to be forwarded there?  I mean, I
don't see anything in info-gnu-emacs that is supposed to post
messages to the group.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: emacs 21.2

[Werner LEMBERG]

> gnu.emacs.announce is empty (0 messages) on the news server I use.
> This is a very good server (news.cis.dfn.de) which carries many GNU
> groups and has very low propagation delay.  Which leads me to the
> conclusion that gnu.emacs.announce didn't see any messages for a
> long time.

Yes, more than three(!) years.  I repeatedly asked for fixing this.


    Werner

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: emacs 21.2

[Richard Stallman]

    > gnu.emacs.announce is empty (0 messages) on the news server I use.
    > This is a very good server (news.cis.dfn.de) which carries many GNU
    > groups and has very low propagation delay.  Which leads me to the
    > conclusion that gnu.emacs.announce didn't see any messages for a
    > long time.

    Yes, more than three(!) years.  I repeatedly asked for fixing this.

We had no one who could do it, so there was nothing we could do.
Perhaps now we can fix it.  I do not know.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: emacs 21.2

[Eli Zaretskii]

> Date: Wed, 27 Mar 2002 21:55:25 -0700 (MST)
> From: Richard Stallman <rms@gnu.org>
> 
>     > gnu.emacs.announce is empty (0 messages) on the news server I use.
>     > This is a very good server (news.cis.dfn.de) which carries many GNU
>     > groups and has very low propagation delay.  Which leads me to the
>     > conclusion that gnu.emacs.announce didn't see any messages for a
>     > long time.
> 
>     Yes, more than three(!) years.  I repeatedly asked for fixing this.
> 
> We had no one who could do it, so there was nothing we could do.
> Perhaps now we can fix it.  I do not know.

One thing I could do is make info-gnu-emacs forward to
gnu.emacs.announce.  But for that, I need to tell mailman the name of
the news server it should use for forwarding.  Can someone tell me
what server to use?

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: emacs 21.2

[Florian Weimer]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

>> We had no one who could do it, so there was nothing we could do.
>> Perhaps now we can fix it.  I do not know.
>
> One thing I could do is make info-gnu-emacs forward to
> gnu.emacs.announce.  But for that, I need to tell mailman the name of
> the news server it should use for forwarding.  Can someone tell me
> what server to use?

The server of your provider?  Usenet is a highly decentralized
infrastructure, and there shouldn't be any public injection points due
to their massive abuse for spamming over the past few years.

If the host on which Mailman is running has got a static IP address, I
could open a news server for this particular host.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: emacs 21.2

[Eli Zaretskii]

> From: Florian Weimer <fw@deneb.enyo.de>
> Date: Fri, 29 Mar 2002 18:15:48 +0100
> 
> "Eli Zaretskii" <eliz@is.elta.co.il> writes:
> 
> >> We had no one who could do it, so there was nothing we could do.
> >> Perhaps now we can fix it.  I do not know.
> >
> > One thing I could do is make info-gnu-emacs forward to
> > gnu.emacs.announce.  But for that, I need to tell mailman the name of
> > the news server it should use for forwarding.  Can someone tell me
> > what server to use?
> 
> The server of your provider?

You don't _want_ to depend on my provider's server, believe me.  Its
propagation delays are *awful*, and a large proportion of articles (I
estimate it at 50%) never show up at all.  I stopped using it long
ago, precisely for that reason.

I would have used the server I'm using now, news.cis.dfn.de, but it
requires username/password authentication, which probably is not
going to work with mailman's forwarding.

> Usenet is a highly decentralized
> infrastructure, and there shouldn't be any public injection points due
> to their massive abuse for spamming over the past few years.

GNU news groups clearly have servers they use for gateways between
them and the corresponding mailing lists.  I assumed I could use one
of those servers in this case.

> If the host on which Mailman is running has got a static IP address, I
> could open a news server for this particular host.

This is something I cannot answer.  Richard, who should I ask?

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: emacs 21.2

[Florian Weimer]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

>> The server of your provider?
>
> You don't _want_ to depend on my provider's server, believe me.  Its
> propagation delays are *awful*, and a large proportion of articles (I
> estimate it at 50%) never show up at all.  I stopped using it long
> ago, precisely for that reason.

I assumed that you were running the Mailman host; if this is not the
case, you should use the newsserver of the Internet provider of that
host.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel