Gnus 5.10 and Emacs' CVS

Gnus 5.10 and Emacs' CVS

[Frank Schmitt]

Hello

Has anybody already taken the task of integrating Gnus 5.10 in Emacs
CVS? I think this should be done ASAP as recent discussions in
emacs-devel indicate, that we'll see a feature freeze soon.

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: Gnus 5.10 and Emacs' CVS

[Sebastian D.B. Krause]

Frank Schmitt <ich@Frank-Schmitt.net> wrote:
> Has anybody already taken the task of integrating Gnus 5.10 in Emacs
> CVS? I think this should be done ASAP as recent discussions in
> emacs-devel indicate, that we'll see a feature freeze soon.

I think Gnus first needs some fixes because it still has some known
bugs. Larsi has created the v5-10 branch in the Gnus CVS for that
but I still don't see any backports of bugfixes (especially
<uektshbot.fsf_-_@xpediantsolutions.com>) or other checkins into
this branch. This branch could also be used to provide a base for
fixes that e.g. could go into the Debian package of Gnus.

Re: Gnus 5.10 and Emacs' CVS

[Jesper Harder]

Frank Schmitt <ich@Frank-Schmitt.net> writes:

> Has anybody already taken the task of integrating Gnus 5.10 in Emacs
> CVS? I think this should be done ASAP as recent discussions in
> emacs-devel indicate, that we'll see a feature freeze soon.

RMS wants encryption out of Gnus.  That's a reasonably big task, and
nobody seems to show a lot of enthusiasm for doing it.  Quite
understandable, since it's not a lot of fun to delibaretely cripple
software.

This change would probably be so big, that it's too much work to
backport.  So I'd suggest that we instead release a new version when
it's done -- there doesn't necessarily have to pass several years
between each release. The name would turn be quite prophetic, too: "No
(crypto) Gnus".


-- 
Jesper Harder                                <http://purl.org/harder/>

Re: Gnus 5.10 and Emacs' CVS

[Henrik Enberg]

Jesper Harder <harder@ifa.au.dk> writes:

> Frank Schmitt <ich@Frank-Schmitt.net> writes:
>
>> Has anybody already taken the task of integrating Gnus 5.10 in Emacs
>> CVS? I think this should be done ASAP as recent discussions in
>> emacs-devel indicate, that we'll see a feature freeze soon.
>
> RMS wants encryption out of Gnus.  That's a reasonably big task, and
> nobody seems to show a lot of enthusiasm for doing it.  Quite
> understandable, since it's not a lot of fun to delibaretely cripple
> software.

Doesn't he want encryption out of whatever Gnus is in Emacs?  That'd
mean ripping it out of some version no matter what.

Of course, I have no idea how much work it is, or how much _more_ work
it would be with 5.10 instead of 5.9.

Re: Gnus 5.10 and Emacs' CVS

[Jesper Harder]

Henrik Enberg <henrik.enberg@telia.com> writes:

> Jesper Harder <harder@ifa.au.dk> writes:
>
>> RMS wants encryption out of Gnus.  That's a reasonably big task,
>> and nobody seems to show a lot of enthusiasm for doing it.  Quite
>> understandable, since it's not a lot of fun to delibaretely cripple
>> software.
>
> Doesn't he want encryption out of whatever Gnus is in Emacs?  

Yes.

> That'd mean ripping it out of some version no matter what.

Yup, but if we did for Gnus 5.9 or Gnus 5.10.6, then we'd have to
forward port it to No Gnus, which means more work than if we did it in
No Gnus.

-- 
Jesper Harder                                <http://purl.org/harder/>

Re: Gnus 5.10 and Emacs' CVS

[Frank Schmitt]

Jesper Harder <harder@ifa.au.dk> writes:

>> That'd mean ripping it out of some version no matter what.
>
> Yup, but if we did for Gnus 5.9 or Gnus 5.10.6, then we'd have to
> forward port it to No Gnus, which means more work than if we did it in
> No Gnus.

Huh? Why should Gnus' CVS Head be crippled just because RMS wants it? I
mean, if he doesn't want encryption in the version delivered with Gnu
Emacs, that's OK, but it should stay in the version released
independent. Otherwise we'd probably piss off and loose a bunch of
users (including me).

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: Gnus 5.10 and Emacs' CVS

[Jesper Harder]

Frank Schmitt <ich@Frank-Schmitt.net> writes:

> Why should Gnus' CVS Head be crippled just because RMS wants it?  

Because nobody wants to maintain two different versions of Gnus, or
repeat all of the work of stripping the crypto code every time a Gnus
release is imported to Emacs.

> I mean, if he doesn't want encryption in the version delivered with
> Gnu Emacs, that's OK, but it should stay in the version released
> independent.

The functionality should stay, of course -- maybe move the files to
/contrib.  The issue is that we have to separate all of the encryption
functionality cleanly to independent files, so that the rest of Gnus
doesn't depend on them.

-- 
Jesper Harder                                <http://purl.org/harder/>

Re: Gnus 5.10 and Emacs' CVS

[Henrik Enberg]

Frank Schmitt <ich@Frank-Schmitt.net> writes:

> Jesper Harder <harder@ifa.au.dk> writes:
>
>>> That'd mean ripping it out of some version no matter what.
>>
>> Yup, but if we did for Gnus 5.9 or Gnus 5.10.6, then we'd have to
>> forward port it to No Gnus, which means more work than if we did it in
>> No Gnus.
>
> Huh? Why should Gnus' CVS Head be crippled just because RMS wants it? I
> mean, if he doesn't want encryption in the version delivered with Gnu
> Emacs, that's OK, but it should stay in the version released
> independent. 

I think that's the general idea.  RMS said that all GNU crypto code
should be distributed from outside the US, and AFAIK gnus.org lives in
Norway. 

Re: Gnus 5.10 and Emacs' CVS

[Henrik Enberg]

Jesper Harder <harder@ifa.au.dk> writes:

[...]

> Yup, but if we did for Gnus 5.9 or Gnus 5.10.6, then we'd have to
> forward port it to No Gnus, which means more work than if we did it in
> No Gnus.

Ahh, that makes sense.

Re: Gnus 5.10 and Emacs' CVS

[Peter Lee]

>>>> Jesper Harder writes:

    >> Frank Schmitt <ich@Frank-Schmitt.net> writes:
    >> Why should Gnus' CVS Head be crippled just because RMS wants
    >> it?

    Jesper> Because nobody wants to maintain two different versions of
    Jesper> Gnus, or repeat all of the work of stripping the crypto
    Jesper> code every time a Gnus release is imported to Emacs.

One obvious solution is to pull it out of Emacs all together.
Maintain it as a seperate package only.

Emacs is bloated as it is.  Those who don't use Gnus currently get it
whether they want it or not.

I know it wouldn't bother me, as I use CVS anyway.  Anyone smart
enough to use Gnus shouldn't have any problems downloading a tarball
and installing it.

Re: Gnus 5.10 and Emacs' CVS

[Romain Francoise]

Peter Lee <pete_lee@swbell.net> writes:

> One obvious solution is to pull it out of Emacs all together.
> Maintain it as a seperate package only.

That is a possibility, especially given that some GNU/Linux
distributions (well, at least Debian) distribute Gnus as a separate
package which is often more up-to-date than the version bundled with
Emacs.

-- 
Romain Francoise <romain@orebokech.com> | And you never lay down and
it's a miracle -- http://orebokech.com/ | you never stay home...

Re: Gnus 5.10 and Emacs' CVS

[Sebastian D.B. Krause]

Romain Francoise <romain@orebokech.com> wrote:
> Peter Lee <pete_lee@swbell.net> writes:
>> One obvious solution is to pull it out of Emacs all together.
>> Maintain it as a seperate package only.
>
> That is a possibility, especially given that some GNU/Linux
> distributions (well, at least Debian) distribute Gnus as a separate
> package which is often more up-to-date than the version bundled with
> Emacs.

And IMO it is the better solution rather than removing any code from
Gnus which many people use. If RMS doesn't like Gnus as it is
currently, then he'll just don't get it into Emacs.

Re: Gnus 5.10 and Emacs' CVS

[Jesper Harder]

Peter Lee <pete_lee@swbell.net> writes:

> One obvious solution is to pull it out of Emacs all together.
> Maintain it as a seperate package only.
>
> Emacs is bloated as it is.  Those who don't use Gnus currently get
> it whether they want it or not.

It's not that simple.  Other parts of Emacs depend on some Gnus
libraries.

> I know it wouldn't bother me, as I use CVS anyway.  Anyone smart
> enough to use Gnus shouldn't have any problems downloading a tarball
> and installing it.

I strongly disagree.  Being bundled with Emacs itself is important --
it increases availability and visibility greatly.  Most people do not
want to hunt down and install third-party packages.

-- 
Jesper Harder                                <http://purl.org/harder/>

Re: Gnus 5.10 and Emacs' CVS

[Miles Bader]

Jesper Harder <harder@ifa.au.dk> writes:
> > I know it wouldn't bother me, as I use CVS anyway.  Anyone smart
> > enough to use Gnus shouldn't have any problems downloading a tarball
> > and installing it.
> 
> I strongly disagree.  Being bundled with Emacs itself is important --
> it increases availability and visibility greatly.  Most people do not
> want to hunt down and install third-party packages.

Yeah, I strongly agree.  Installing extra packages is always a pain, and
requiring it would make Gnus less usable for many people.  Gnus is
important enough that users shouldn't have to do that.

The thing about encryption is very unfortunate, but AFAICS, RMS has
pretty good reasons for it.

[This sort of thing always seems to be a signal for anyone that dislikes
RMS to drag out their standard rants.  Please people...]

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

Re: Gnus 5.10 and Emacs' CVS

[Kevin Greiner]

krause@sdbk.de (Sebastian D.B. Krause) writes:

> Frank Schmitt <ich@Frank-Schmitt.net> wrote:
>> Has anybody already taken the task of integrating Gnus 5.10 in Emacs
>> CVS? I think this should be done ASAP as recent discussions in
>> emacs-devel indicate, that we'll see a feature freeze soon.
>
> I think Gnus first needs some fixes because it still has some known
> bugs. Larsi has created the v5-10 branch in the Gnus CVS for that
> but I still don't see any backports of bugfixes (especially
> <uektshbot.fsf_-_@xpediantsolutions.com>) or other checkins into
> this branch. This branch could also be used to provide a base for
> fixes that e.g. could go into the Debian package of Gnus.

I'll try to get the agent patches backported this week.

Kevin

Proposed Changes

[Kevin Greiner]

krause@sdbk.de (Sebastian D.B. Krause) writes:

> Frank Schmitt <ich@Frank-Schmitt.net> wrote:
>> Has anybody already taken the task of integrating Gnus 5.10 in Emacs
>> CVS? I think this should be done ASAP as recent discussions in
>> emacs-devel indicate, that we'll see a feature freeze soon.
>
> I think Gnus first needs some fixes because it still has some known
> bugs. Larsi has created the v5-10 branch in the Gnus CVS for that
> but I still don't see any backports of bugfixes (especially
> <uektshbot.fsf_-_@xpediantsolutions.com>) or other checkins into
> this branch. This branch could also be used to provide a base for
> fixes that e.g. could go into the Debian package of Gnus.

I'd like to get a clarification on how the v5-10 branch is to be
handled.  I'd like to move the v5-10-6 tag from revision 6.27 to 7.2
for gnus-cus.el and from 6.186 to 7.7 for gnus-agent.el.  While the
simpliest technical solution, it modifies v5-10-6 without leaving any
historical record.  Alternative solutions, are to either create a
v5-10-7 tag or to perform the actual code check-in.  Opinions?

Kevin

Re: Proposed Changes

[Reiner Steib]

On Tue, Apr 13 2004, Kevin Greiner wrote:

> krause@sdbk.de (Sebastian D.B. Krause) writes:
>> Larsi has created the v5-10 branch in the Gnus CVS for that but I
>> still don't see any backports of bugfixes (especially
>> <uektshbot.fsf_-_@xpediantsolutions.com>) or other checkins into
>> this branch. This branch could also be used to provide a base for
>> fixes that e.g. could go into the Debian package of Gnus.
>
> I'd like to get a clarification on how the v5-10 branch is to be
> handled.  

I think you can simply do a checkout of this branch and commit the
bugfixes (possibly backported from the trunk) there:

  mkdir 5-10
  cd 5-10
  cvs -d :pserver:YOURLOGIN@cvs.gnus.org:/usr/local/cvsroot co -r v5-10 gnus 

[ I'm not aware of a more simple possibility, but I'm not too familiar
with cvs branches. ]

We can also check in post-5.10.6 other bug- and doc-fixes in this
branch, I think.  Maybe going thru the articles in
gmane.emacs.gnus.commit (or the ChangeLog files) and check for
doc-fixes and similar would be a good idea and/or do such check-ins in
both branches from now on.

> I'd like to move the v5-10-6 tag from revision 6.27 to 7.2 for
> gnus-cus.el and from 6.186 to 7.7 for gnus-agent.el.  While the
> simpliest technical solution, it modifies v5-10-6 without leaving
> any historical record.

I don't think this is a good idea.

> Alternative solutions, are to either create a v5-10-7 tag or to
> perform the actual code check-in.

I think a v5-10-7 should not be created unless Lars is doing a release
numbered 5.10.7.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: Proposed Changes

[Kevin Greiner]

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:

> On Tue, Apr 13 2004, Kevin Greiner wrote:
>
>> krause@sdbk.de (Sebastian D.B. Krause) writes:
>>> Larsi has created the v5-10 branch in the Gnus CVS for that but I
>>> still don't see any backports of bugfixes (especially
>>> <uektshbot.fsf_-_@xpediantsolutions.com>) or other checkins into
>>> this branch. This branch could also be used to provide a base for
>>> fixes that e.g. could go into the Debian package of Gnus.
>>
>> I'd like to get a clarification on how the v5-10 branch is to be
>> handled.  
>
> I think you can simply do a checkout of this branch and commit the
> bugfixes (possibly backported from the trunk) there:
>
>   mkdir 5-10
>   cd 5-10
>   cvs -d :pserver:YOURLOGIN@cvs.gnus.org:/usr/local/cvsroot co -r v5-10 gnus 
>
> [ I'm not aware of a more simple possibility, but I'm not too familiar
> with cvs branches. ]

Right choice.  I had forgotten that Lars had already set up the branch
point.

I've updated gnus-agent.el and gnus-cus.el to resolve the agent
performance issues in v5-10.  If I get some positive feedback, I'll
know that it is safe to try to backport the imap integration patches
(So that the agent and cache handle article movement, group renaming,
and group deletion correctly).

Kevin

Re: Proposed Changes

[Kai Grossjohann]

Kevin Greiner <kgreiner@xpediantsolutions.com> writes:

> I've updated gnus-agent.el and gnus-cus.el to resolve the agent
> performance issues in v5-10.  If I get some positive feedback, I'll
> know that it is safe to try to backport the imap integration patches
> (So that the agent and cache handle article movement, group renaming,
> and group deletion correctly).

I agere that this is a good idea, but please note that Lars has been
quite conservative before and interpreted the word bug fix in a quite
narrow way.

So if it was me, I'd make sure that Lars says okay before committing
things that could be construed new features.  But that's just my VHO.

Kai

Re: Proposed Changes

[Kevin Greiner]

Kai Grossjohann <kai@emptyhost.emptydomain.de> writes:

> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>
>> I've updated gnus-agent.el and gnus-cus.el to resolve the agent
>> performance issues in v5-10.  If I get some positive feedback, I'll
>> know that it is safe to try to backport the imap integration patches
>> (So that the agent and cache handle article movement, group renaming,
>> and group deletion correctly).
>
> I agere that this is a good idea, but please note that Lars has been
> quite conservative before and interpreted the word bug fix in a quite
> narrow way.
>
> So if it was me, I'd make sure that Lars says okay before committing
> things that could be construed new features.  But that's just my VHO.

Good point.

To clarify the issue, the cache and agent were originally designed for
the nntp backend.  As a result, they are simply ignored when non-nntp
commands (such as renaming a group) are performed.  A number of
threads have reported problems with moved articles not
disappearing or showing the wrong content.  I agree that Lars will
have to decide whether enhancing the cache and agent to better support
imap is a new feature or a bug fix.

Kevin

Re: Proposed Changes

[Kai Grossjohann]

Kevin Greiner <kgreiner@xpediantsolutions.com> writes:

> To clarify the issue, the cache and agent were originally designed for
> the nntp backend.  As a result, they are simply ignored when non-nntp
> commands (such as renaming a group) are performed.  A number of
> threads have reported problems with moved articles not
> disappearing or showing the wrong content.  I agree that Lars will
> have to decide whether enhancing the cache and agent to better support
> imap is a new feature or a bug fix.

Ah!  I misread "fixing agent performance issues" as saying that you
optimized something and now Gnus is faster.

The new description sounds much more like a bugfix!

Kai

Re: Proposed Changes

[Lars Magne Ingebrigtsen]

Kevin Greiner <kgreiner@xpediantsolutions.com> writes:

> To clarify the issue, the cache and agent were originally designed for
> the nntp backend.  As a result, they are simply ignored when non-nntp
> commands (such as renaming a group) are performed.  A number of
> threads have reported problems with moved articles not
> disappearing or showing the wrong content.  I agree that Lars will
> have to decide whether enhancing the cache and agent to better support
> imap is a new feature or a bug fix.

I think this sounds more like a new feature than a bug fix, actually...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Proposed Changes

[Kai Grossjohann]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>
>> To clarify the issue, the cache and agent were originally designed for
>> the nntp backend.  As a result, they are simply ignored when non-nntp
>> commands (such as renaming a group) are performed.  A number of
>> threads have reported problems with moved articles not
>> disappearing or showing the wrong content.  I agree that Lars will
>> have to decide whether enhancing the cache and agent to better support
>> imap is a new feature or a bug fix.
>
> I think this sounds more like a new feature than a bug fix, actually...

I'm surprised.

OT1H extending the Agent to handle moves sounds like a new feature.
But OTOH, Gnus displaying the wrong article contents surely sounds
like a bug.

Kai

Re: Proposed Changes

[Lars Magne Ingebrigtsen]

Kai Grossjohann <kai.grossjohann@gmx.net> writes:

> OT1H extending the Agent to handle moves sounds like a new feature.
> But OTOH, Gnus displaying the wrong article contents surely sounds
> like a bug.

Well...  yes, it's a bug, but the fix is kinda major.  And only
serious problems should be fixed in the stable series...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen