Re: pop3.el: Display the size of the message being fetched (POP3 LIST command)

Re: pop3.el: Display the size of the message being fetched (POP3 LIST command)

[Bojan Petrovic]

> That looks useful; have you signed papers to contribute?  Also, can you
> add a few lines to the manual listing the new variable?

I'd be glad to sign them, but I am not familiar with procedure.

I'm sending the changelog, the texinfo patch, and a slightly revised 
previous patch: I've changed the commentary to reflect the addition of 
pop3-list, the docstring of pop3-list and the version number in 
defcustom (23.1).

Please tell me if any changes are needed.



Regards,

Bojan




--snip----------------------------------------------------

2009-02-07  Bojan Petrovic  <bpetrovi@f.bg.ac.rs>

	* gnus.texi (Mail Source Specifiers): Describe
	`pop3-display-message-size-flag' and add it to the index.


2009-02-07  Bojan Petrovic  <bpetrovi@f.bg.ac.rs>

	* pop3.el (pop3-list): Implement the POP3 LIST command.
	(global): Change the commentary to reflect the above change.
	(pop3-movemail): Optionally display the size of the message that
	is being fetched.
	(pop3-display-message-size-flag): New variable.




--snip----------------------------------------------------

Index: gnus.texi
===================================================================
RCS file: /sources/emacs/emacs/doc/misc/gnus.texi,v
retrieving revision 1.40
diff -u -r1.40 gnus.texi
--- gnus.texi	19 Jan 2009 01:06:25 -0000	1.40
+++ gnus.texi	7 Feb 2009 21:57:47 -0000
@@ -15224,6 +15224,11 @@
 do not, then you may get duplicate mails or the whole thing can fall
 apart and leave you with a corrupt mailbox.
 
+@vindex pop3-display-message-size-flag
+If @code{pop3-display-message-size-flag} is non-@code{nil}, the size
+in kilobytes of the message that is being fetched will be displayed in
+the echo area.
+
 Here are some examples for getting mail from a @acronym{POP} server.
 Fetch from the default @acronym{POP} server, using the default user
 name, and default fetcher:



--snip----------------------------------------------------

Index: pop3.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/gnus/pop3.el,v
retrieving revision 1.50
diff -u -r1.50 pop3.el
--- pop3.el	9 Jan 2009 03:01:52 -0000	1.50
+++ pop3.el	7 Feb 2009 21:51:15 -0000
@@ -24,9 +24,8 @@
 
 ;;; Commentary:
 
-;; Most of the standard Post Office Protocol version 3 (RFC 1460) commands
-;; are implemented.  The LIST command has not been implemented due to lack
-;; of actual usefulness.
+;; The entire Post Office Protocol version 3 (RFC 1460) minimal
+;; command set and the optional APOP command are implemented.
 ;; The optional POP3 command TOP has not been implemented.
 
 ;; This program was inspired by Kyle E. Jones's vm-pop program.
@@ -98,6 +97,12 @@
   :type 'boolean
   :group 'pop3)
 
+(defcustom pop3-display-message-size-flag t
+  "*If non-nil, display the size of the message that is being fetched."
+  :version "23.1" ;; No Gnus
+  :type 'boolean
+  :group 'pop3)
+
 (defvar pop3-timestamp nil
   "Timestamp returned when initially connected to the POP server.
 Used for APOP authentication.")
@@ -135,6 +140,7 @@
 	 (crashbuf (get-buffer-create " *pop3-retr*"))
 	 (n 1)
 	 message-count
+	 message-sizes
 	 (pop3-password pop3-password))
     ;; for debugging only
     (if pop3-debug (switch-to-buffer (process-buffer process)))
@@ -149,10 +155,18 @@
 	   (pop3-pass process))
 	  (t (error "Invalid POP3 authentication scheme")))
     (setq message-count (car (pop3-stat process)))
+    (when (and pop3-display-message-size-flag
+	       (> message-count 0))
+      (setq message-sizes (pop3-list process)))
     (unwind-protect
 	(while (<= n message-count)
-	  (message "Retrieving message %d of %d from %s..."
-		   n message-count pop3-mailhost)
+	  (if pop3-display-message-size-flag
+	      (message "Retrieving message %d of %d from %s... (%.1fk)"
+		       n message-count pop3-mailhost
+		       (/ (cdr (assoc n message-sizes))
+			  1024.0))
+	    (message "Retrieving message %d of %d from %s..."
+		     n message-count pop3-mailhost))
 	  (pop3-retr process n crashbuf)
 	  (save-excursion
 	    (set-buffer crashbuf)
@@ -451,8 +465,27 @@
     ))
 
 (defun pop3-list (process &optional msg)
-  "Scan listing of available messages.
-This function currently does nothing.")
+  "Return an alist of (MESSAGE-ID . SIZE) pairs.
+If MSG is supplied, return the size of the message-id MSG"
+  (pop3-send-command process (if msg
+				 (format "LIST %d" msg)
+			       "LIST"))
+  (let ((response (pop3-read-response process t)))
+    (if msg
+	(string-to-number (nth 2 (split-string response " ")))
+      (let ((start pop3-read-point) end)
+	(save-excursion
+	  (set-buffer (process-buffer process))
+	  (while (not (re-search-forward "^\\.\r\n" nil t))
+	    (pop3-accept-process-output process)
+	    (goto-char start))
+	  (setq pop3-read-point (point-marker))
+	  (goto-char (match-beginning 0))
+	  (setq end (point-marker))
+	  (mapcar #'(lambda (s) (let ((split (split-string s " ")))
+				  (cons (string-to-number (nth 0 split))
+					(string-to-number (nth 1 split)))))
+		  (split-string (buffer-substring start end) "\r\n" t)))))))
 
 (defun pop3-retr (process msg crashbuf)
   "Retrieve message-id MSG to buffer CRASHBUF."



-- 
http://www.fastmail.fm - The professional email service

Re: pop3.el: Display the size of the message being fetched (POP3 LIST command)

[Ted Zlatanov]

On Sun, 08 Feb 2009 00:35:54 +0100 "Bojan Petrovic" <bojan_petrovic@fastmail.fm> wrote: 

>> That looks useful; have you signed papers to contribute?  Also, can you
>> add a few lines to the manual listing the new variable?

BP> I'd be glad to sign them, but I am not familiar with procedure.

Reiner Steib has done it in the past, I believe.  I usually check
http://www.gnu.org/prep/maintain/html_node/Copyright-Papers.html for the
info but you may want to look through
http://www.gnu.org/prep/maintain/html_node/Legal-Matters.html in general
if you're interested, to understand why the assignment is necessary and
what it means.

BP> I'm sending the changelog, the texinfo patch, and a slightly revised 
BP> previous patch: I've changed the commentary to reflect the addition of 
BP> pop3-list, the docstring of pop3-list and the version number in 
BP> defcustom (23.1).

The code looks OK to me, but I don't use POP3 so I can't test it.  If no
one else can test it, I'll set up a POP3 server.

Ted

Re: pop3.el: Display the size of the message being fetched (POP3 LIST command)

[Reiner Steib]

On Mon, Feb 09 2009, Ted Zlatanov wrote:

> On Sun, 08 Feb 2009 00:35:54 +0100 "Bojan Petrovic" <bojan_petrovic@fastmail.fm> wrote: 
>
>>> That looks useful; have you signed papers to contribute?  Also, can you
>>> add a few lines to the manual listing the new variable?
>
> BP> I'd be glad to sign them, 

Thanks!

> BP> but I am not familiar with procedure.
>
> Reiner Steib has done it in the past, I believe.  

-> personal mail to Bojan and Ted.

> BP> I'm sending the changelog, the texinfo patch, and a slightly revised 
> BP> previous patch: I've changed the commentary to reflect the addition of 
> BP> pop3-list, the docstring of pop3-list and the version number in 
> BP> defcustom (23.1).
>
> The code looks OK to me, but I don't use POP3 so I can't test it.  If no
> one else can test it, I'll set up a POP3 server.

Please don't install it before the paper work is complete.  Also, as
it's not a bug fix, it should not be installed now.

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

Re: pop3.el: Display the size of the message being fetched (POP3 LIST command)

[Katsumi Yamaoka]

>>>>> Reiner Steib wrote:
> On Mon, Feb 09 2009, Ted Zlatanov wrote:
>> The code looks OK to me, but I don't use POP3 so I can't test it.  If no
>> one else can test it, I'll set up a POP3 server.

With the "Microsoft Exchange Server 2007 POP3 server" I've tested
Bojan's patch.  Works fine.

nnml: Reading incoming mail from pop...
Retrieving message 1 of 2 from pop.jp.example.com... (2.8k)
Retrieving message 2 of 2 from pop.jp.example.com... (3.9k)

BTW, isn't `pop3-display-message-size', the name of the option,
enough rather than `pop3-display-message-size-flag'?

> Please don't install it before the paper work is complete.  Also, as
> it's not a bug fix, it should not be installed now.

I agree.

Re: pop3.el: Display the size of the message being fetched (POP3 LIST command)

[Bojan Petrovic]

Katsumi Yamaoka <yamaoka@jpl.org> said:
> BTW, isn't `pop3-display-message-size', the name of the option,
> enough rather than `pop3-display-message-size-flag'?

Yes, the name is really long, but I followed (and possibly 
misapplied) the advice from Emacs "Coding Conventions":

* If a user option variable records a true-or-false condition, give
     it a name that ends in `-flag'.



Regards,

Bojan


-- 
http://www.fastmail.fm - One of many happy users:
  http://www.fastmail.fm/docs/quotes.html

Re: pop3.el: Display the size of the message being fetched (POP3 LIST command)

[Ted Zlatanov]

On Tue, 10 Feb 2009 08:07:58 +0900 Katsumi Yamaoka <yamaoka@jpl.org> wrote: 

>>>>>> Reiner Steib wrote:
>> Please don't install it before the paper work is complete.  Also, as
>> it's not a bug fix, it should not be installed now.

KY> I agree.

I wouldn't dream of it :)

On Tue, 10 Feb 2009 00:38:27 +0100 "Bojan Petrovic" <bojan_petrovic@fastmail.fm> wrote: 

BP> Katsumi Yamaoka <yamaoka@jpl.org> said:
>> BTW, isn't `pop3-display-message-size', the name of the option,
>> enough rather than `pop3-display-message-size-flag'?

BP> Yes, the name is really long, but I followed (and possibly 
BP> misapplied) the advice from Emacs "Coding Conventions":

BP> * If a user option variable records a true-or-false condition, give
BP>      it a name that ends in `-flag'.

In addition, "*-size" would imply it customizes a size at first glance.
So I like the p-d-m-s-flag name better too.

Ted

Re: pop3.el: Display the size of the message being fetched (POP3 LIST command)

[Reiner Steib]

[ The following message is a courtesy copy of an article that has
  been posted to news:gmane.emacs.gnus.general as well. ]

On Tue, Feb 10 2009, Ted Zlatanov wrote:

> "Bojan Petrovic" <bojan_petrovic@fastmail.fm> wrote: 
> BP> Katsumi Yamaoka <yamaoka@jpl.org> said:
>>> BTW, isn't `pop3-display-message-size', the name of the option,
>>> enough rather than `pop3-display-message-size-flag'?
>
> BP> Yes, the name is really long, but I followed (and possibly 
> BP> misapplied) the advice from Emacs "Coding Conventions":
>
> BP> * If a user option variable records a true-or-false condition, give
> BP>      it a name that ends in `-flag'.

At least one of the current Emacs maintainers (Stefan) disagrees with
this convention.  I don't like it as well, since boolean options often
are extended to allow other values.  The the option would have to be
renamed.  

In Gnus, we never really followed this convention:

,----
| -*- mode: grep; default-directory: "gnus/trunk/lisp/" -*-
| Grep started at Tue Feb 10 23:16:09
| 
| grep -nH -e '^(def.*-flag\>' *.el
| gnus-bookmark.el:91:(defcustom gnus-bookmark-sort-flag t
| imap.el:1756:(defun imap-message-flag-permanent-p (flag &optional mailbox buffer)
| imap.el:2689:(defun imap-parse-flag-list ()
| nnimap.el:1702:(defconst nnimap-mark-to-flag-alist
| nnimap.el:1715:(defun nnimap-mark-to-flag-1 (preds)
| nnimap.el:1721:(defun nnimap-mark-to-flag (preds &optional always-list make-string)
| spam.el:589:(defcustom spam-spamassassin-spam-flag-header "X-Spam-Flag"
| spam.el:594:(defcustom spam-spamassassin-positive-spam-flag-header "YES"
| 
| Grep finished (matches found) at Tue Feb 10 23:16:10
`----

> In addition, "*-size" would imply it customizes a size at first glance.

Not really.  `pop3-display-message-size' is clear IMHO.

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

Re: pop3.el: Display the size of the message being fetched (POP3 LIST command)

[Bojan Petrovic]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

>> In addition, "*-size" would imply it customizes a size at first glance.
>
> Not really.  `pop3-display-message-size' is clear IMHO.

Naming it `pop3-show-message-size' could remove the (possible)
ambiguity, but the term `show` seems to be more frequently used when
talking about pictures or some elements of the UI.

`print'? `echo'? They are similar to `display'...

I'm OK with `pop3-display-message-size'.



Regards,

Bojan.

Re: pop3.el: Display the size of the message being fetched (POP3 LIST command)

[Bojan Petrovic]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

>> BP> I'd be glad to sign them, 
>
> Thanks!

I have signed the papers and recieved the signed pdf (#410945).



Regards,

Bojan.

Re: pop3.el: Display the size of the message being fetched (POP3 LIST command)

[Ted Zlatanov]

On Wed, 01 Apr 2009 21:21:08 +0000 Bojan Petrovic <bpetrovi@f.bg.ac.rs> wrote: 

BP> Reiner Steib <reinersteib+gmane@imap.cc> writes:
BP> I'd be glad to sign them, 
>> 
>> Thanks!

BP> I have signed the papers and recieved the signed pdf (#410945).

Reiner can confirm, but I believe we're in a feature freeze right now so
your patch will be comitted after the Emacs pretest is done.

Reiner, do you want me to do the commit?

Thank you
Ted

Re: pop3.el: Display the size of the message being fetched (POP3 LIST command)

[Reiner Steib]

On Mon, Apr 13 2009, Ted Zlatanov wrote:

> On Wed, 01 Apr 2009 Bojan Petrovic <bpetrovi@f.bg.ac.rs> wrote: 
> BP> I have signed the papers and recieved the signed pdf (#410945).
>
> Reiner can confirm, but I believe we're in a feature freeze right now so
> your patch will be comitted after the Emacs pretest is done.

Yes.

> Reiner, do you want me to do the commit?

If someone thinks installing this (or any other non-bugfix path)
should not wait, please bring the issue up on emacs-devel so that the
Emacs maintainers can decide.  Thanks.

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

Re: pop3.el: Display the size of the message being fetched (POP3 LIST command)

[Ted Zlatanov]

On Thu, 16 Apr 2009 21:06:58 +0200 Reiner Steib <reinersteib+gmane@imap.cc> wrote: 

RS> On Mon, Apr 13 2009, Ted Zlatanov wrote:
>> Reiner can confirm, but I believe we're in a feature freeze right now so
>> your patch will be comitted after the Emacs pretest is done.

RS> Yes.

>> Reiner, do you want me to do the commit?

RS> If someone thinks installing this (or any other non-bugfix path)
RS> should not wait, please bring the issue up on emacs-devel so that the
RS> Emacs maintainers can decide.  Thanks.

I meant "do you want me to do the commit after the feature freeze."
Sorry for the confusion.

Thanks
Ted

Re: pop3.el: Display the size of the message being fetched (POP3 LIST command)

[Ted Zlatanov]

On Thu, 16 Apr 2009 15:08:33 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Thu, 16 Apr 2009 21:06:58 +0200 Reiner Steib <reinersteib+gmane@imap.cc> wrote: 
RS> On Mon, Apr 13 2009, Ted Zlatanov wrote:
>>> Reiner can confirm, but I believe we're in a feature freeze right now so
>>> your patch will be comitted after the Emacs pretest is done.

RS> Yes.

>>> Reiner, do you want me to do the commit?

RS> If someone thinks installing this (or any other non-bugfix path)
RS> should not wait, please bring the issue up on emacs-devel so that the
RS> Emacs maintainers can decide.  Thanks.

TZ> I meant "do you want me to do the commit after the feature freeze."
TZ> Sorry for the confusion.

Reiner, can we commit this patch now?

Thanks
Ted

Re: pop3.el: Display the size of the message being fetched (POP3 LIST command)

[Bojan Petrovic]

Ted Zlatanov <tzz <at> lifelogs.com> writes:

> >>> Reiner, do you want me to do the commit?
> 
> RS> If someone thinks installing this (or any other non-bugfix path)
> RS> should not wait, please bring the issue up on emacs-devel so that the
> RS> Emacs maintainers can decide.  Thanks.
> 
> TZ> I meant "do you want me to do the commit after the feature freeze."
> TZ> Sorry for the confusion.
> 
> Reiner, can we commit this patch now?
> 
> Thanks
> Ted


Hi,

I just wanted to revive this thread, if it died inadvertently.

Does anyone still think that this patch might be useful?

Regards,

Bojan

Re: pop3.el: Display the size of the message being fetched (POP3 LIST command)

[Ted Zlatanov]

On Fri, 25 Dec 2009 20:07:02 +0000 (UTC) Bojan Petrovic <bpetrovi@f.bg.ac.rs> wrote: 

BP> Ted Zlatanov <tzz <at> lifelogs.com> writes:
>> >>> Reiner, do you want me to do the commit?
>> 
RS> If someone thinks installing this (or any other non-bugfix path)
RS> should not wait, please bring the issue up on emacs-devel so that the
RS> Emacs maintainers can decide.  Thanks.
>> 
TZ> I meant "do you want me to do the commit after the feature freeze."
TZ> Sorry for the confusion.
>> 
>> Reiner, can we commit this patch now?
>> 
>> Thanks
>> Ted

BP> I just wanted to revive this thread, if it died inadvertently.

BP> Does anyone still think that this patch might be useful?

I didn't get a reply from Reiner AFAIK and forgot to ping him back.  I
am still in favor of installing your patch but will defer to Reiner on
when it actually happens.

Ted

Re: pop3.el: Display the size of the message being fetched (POP3 LIST command)

[Reiner Steib]

On Tue, Jan 05 2010, Ted Zlatanov wrote:

> On Fri, 25 Dec 2009 20:07:02 +0000 (UTC) Bojan Petrovic <bpetrovi@f.bg.ac.rs> wrote: 
>
> BP> Ted Zlatanov <tzz <at> lifelogs.com> writes:
>>> >>> Reiner, do you want me to do the commit?
>>> 
> RS> If someone thinks installing this (or any other non-bugfix path)
> RS> should not wait, please bring the issue up on emacs-devel so that the
> RS> Emacs maintainers can decide.  Thanks.
>>> 
> TZ> I meant "do you want me to do the commit after the feature freeze."
> TZ> Sorry for the confusion.
[...]
> I didn't get a reply from Reiner AFAIK and forgot to ping him back.  I
> am still in favor of installing your patch but will defer to Reiner on
> when it actually happens.

Were basically in the same situation again, as now Emacs is in pretest
for 23.2.

In fact we should probably create a branch for Gnus 5.13 (Emacs 23)
and install non-bugfixes on the trunk.  But that's for Lars to decide.

Bye, Reiner.

[ Resent via mail. Sorry if the posting thru Gmane arrives too. ]
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Gnus VCS issues (was: pop3.el: Display the size of the message being fetched (POP3 LIST command))

[Ted Zlatanov]

On Tue, 12 Jan 2010 18:16:41 +0100 Reiner Steib <reinersteib+gmane@imap.cc> wrote: 

RS> On Tue, Jan 05 2010, Ted Zlatanov wrote:

>> I didn't get a reply from Reiner AFAIK and forgot to ping him back.  I
>> am still in favor of installing your patch but will defer to Reiner on
>> when it actually happens.

RS> Were basically in the same situation again, as now Emacs is in pretest
RS> for 23.2.

RS> In fact we should probably create a branch for Gnus 5.13 (Emacs 23)
RS> and install non-bugfixes on the trunk.  But that's for Lars to decide.

On Mon, 11 Jan 2010 21:08:21 +0100 Reiner Steib <reinersteib+gmane@imap.cc> wrote: 

RS> But the last time (one year ago) when I wrote to Lars about release
RS> plans (it was about Gnus 5.10.12), I didn't get any reply.  So I was
RS> not enthusiastic about working on further releases that won't get
RS> published.  But I will give it a try again, I think.

Would it make sense at this point to migrate Gnus out of CVS?

Whether we use Subversion or Git or Bazaar, let's use something more
reasonable.  It would make sync with Emacs, branching, tagging, and
releasing simpler.  A DVCS is IMHO the best choice today and I would
support either Git or Bazaar.

We could still host it on gnus.org, of course, and the old CVS server
could be available as a read-only mirror.  But it could live on Savannah
as well.

Lars?

Ted

Re: Gnus VCS issues

[Bojan Nikolic]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Whether we use Subversion or Git or Bazaar, let's use something more
> reasonable.  It would make sync with Emacs, branching, tagging, and
> releasing simpler.  A DVCS is IMHO the best choice today and I would
> support either Git or Bazaar.
>
> We could still host it on gnus.org, of course, and the old CVS server
> could be available as a read-only mirror.  But it could live on Savannah
> as well.

I'm not much of a contributor but I think standardising on Bazaar would
make entry into Gnus development much easier. I hope this can be done.

-- 
Bojan Nikolic          ||          http://www.bnikolic.co.uk

Re: Gnus VCS issues

[Reiner Steib]

On Wed, Jan 13 2010, Ted Zlatanov wrote:

> On Tue, 12 Jan 2010 18:16:41 +0100 Reiner Steib wrote: 
>
> RS> In fact we should probably create a branch for Gnus 5.13 (Emacs 23)
> RS> and install non-bugfixes on the trunk.  But that's for Lars to decide.
>
> On Mon, 11 Jan 2010 21:08:21 +0100 Reiner Steib wrote: 
>
> RS> But the last time (one year ago) when I wrote to Lars about release
> RS> plans (it was about Gnus 5.10.12), I didn't get any reply.  So I was
> RS> not enthusiastic about working on further releases that won't get
> RS> published.  But I will give it a try again, I think.
>
> Would it make sense at this point to migrate Gnus out of CVS?

What I wrote is independent from the VC system we use.

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

Re: Gnus VCS issues

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> RS> But the last time (one year ago) when I wrote to Lars about release
> RS> plans (it was about Gnus 5.10.12), I didn't get any reply.  So I was
> RS> not enthusiastic about working on further releases that won't get
> RS> published.  But I will give it a try again, I think.

Sorry; I totally fumbled that one...

> Would it make sense at this point to migrate Gnus out of CVS?
>
> Whether we use Subversion or Git or Bazaar, let's use something more
> reasonable.  It would make sync with Emacs, branching, tagging, and
> releasing simpler.  A DVCS is IMHO the best choice today and I would
> support either Git or Bazaar.
>
> We could still host it on gnus.org, of course, and the old CVS server
> could be available as a read-only mirror.  But it could live on Savannah
> as well.

I don't really know how much time I could promise to spend on doing
something like that...

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

Re: Gnus VCS issues

[Ted Zlatanov]

On Tue, 19 Jan 2010 23:04:22 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:

>> Would it make sense at this point to migrate Gnus out of CVS?
>> 
>> Whether we use Subversion or Git or Bazaar, let's use something more
>> reasonable.  It would make sync with Emacs, branching, tagging, and
>> releasing simpler.  A DVCS is IMHO the best choice today and I would
>> support either Git or Bazaar.
>> 
>> We could still host it on gnus.org, of course, and the old CVS server
>> could be available as a read-only mirror.  But it could live on Savannah
>> as well.

LMI> I don't really know how much time I could promise to spend on doing
LMI> something like that...

If you're too busy, maybe you'll agree to move the Gnus repo to Savannah
(using Bazaar there).  Then gnus.org can simply point to the Savannah
page for checkouts, tarballs, and the web pages (which can also host the
manual snapshots).  So from your side it's a one-time effort to migrate
CVS and set up the website links; I think Reiner and I (if Reiner
agrees to this plan) can handle the rest.

Ted

Re: Gnus VCS issues

[Andreas Schwab]

Ted Zlatanov <tzz@lifelogs.com> writes:

> So from your side it's a one-time effort to migrate CVS and set up the
> website links; I think Reiner and I (if Reiner agrees to this plan)
> can handle the rest.

I'd offer to do the conversion to bzr.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Gnus VCS issues

[Adam Sjøgren]

What are the pros of Bazaar compared to Git?


  Just curious,

    Adam

-- 
 "But we are stubborn."                                       Adam Sjøgren
                                                         asjo@koldfront.dk

Re: Gnus VCS issues

[Reiner Steib]

On Wed, Jan 20 2010, Adam Sjøgren wrote:

> What are the pros of Bazaar compared to Git?

Emacs uses Bazaar (mainly because it is a GNU project, see the long
discussions in the emacs-devel archive) and we should use the same VC
system as Emacs to make synching easier and so that Gnus developers
don't need to learn another VC system (most active Gnus developers are
also Emacs developers).

(I didn't use neither Bazaar not Git yet.)

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

Re: Gnus VCS issues

[Adam Sjøgren]

On Wed, 20 Jan 2010 23:36:50 +0100, Reiner wrote:

> On Wed, Jan 20 2010, Adam Sjøgren wrote:

>> What are the pros of Bazaar compared to Git?

> Emacs uses Bazaar (mainly because it is a GNU project, see the long
> discussions in the emacs-devel archive) and we should use the same VC
> system as Emacs to make synching easier and so that Gnus developers
> don't need to learn another VC system (most active Gnus developers are
> also Emacs developers).

> (I didn't use neither Bazaar not Git yet.)

(I like Git, and haven't tried Bazaar (except a light brush with the
predecessor tla a long time ago), that was why I asked).

For what it is worth, XEmacs uses Mercurial these days.

On Thu, 21 Jan 2010 00:17:37 +0100, Andreas wrote:

> Tell me when you find one :-)

What I extract from your answers is something like "It's not
sufficiently worse than Git to not choose it for compability reasons".

Makes sense, I guess. As I said, I was just curious and certainly not
trying to light a flame.

The corporate sponsorship background of Bazaar might be worrying, but it
is probably "big" enough that it doesn't matter.


  Thanks,

   Adam

-- 
 "But we are stubborn."                                       Adam Sjøgren
                                                         asjo@koldfront.dk

Re: Gnus VCS issues

[Christian]

>>>>> "Adam" == Adam Sjøgren <asjo@koldfront.dk> writes:

Adam> The corporate sponsorship background of Bazaar might be worrying,
Adam> but it is probably "big" enough that it doesn't matter.

If Stallmann is ok with that, I am sure we need not worry about it :-)


------------------------+-----------------------------------------------------
Christian Lynbech       | christian #\@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
                                        - petonic@hal.com (Michael A. Petonic)

Re: Gnus VCS issues

[Adam Sjøgren]

On Fri, 22 Jan 2010 08:11:14 +0100, Christian wrote:

> If Stallmann is ok with that, I am sure we need not worry about it :-)

I would not default to that.


  :-),

   Adam

-- 
 "May the force be...                                         Adam Sjøgren
  ... equal to mass · acceleration"                      asjo@koldfront.dk

Re: Gnus VCS issues

[Miles Bader]

asjo@koldfront.dk (Adam Sjøgren) writes:
>> If Stallmann is ok with that, I am sure we need not worry about it :-)
>
> I would not default to that.

Agreed; there are many things rms simply doesn't know about.

-Miles

-- 
Faith, n. Belief without evidence in what is told by one who speaks without
knowledge, of things without parallel.

Re: Gnus VCS issues

[Florian Weimer]

* Reiner Steib:

> On Wed, Jan 20 2010, Adam Sjøgren wrote:
>
>> What are the pros of Bazaar compared to Git?
>
> Emacs uses Bazaar (mainly because it is a GNU project, see the long
> discussions in the emacs-devel archive) and we should use the same VC
> system as Emacs to make synching easier and so that Gnus developers
> don't need to learn another VC system (most active Gnus developers are
> also Emacs developers).

Can Bazaar handle such cross-project merges automatically?  (AFAIK,
Git's tool support for this is a bit poor.)

Re: Gnus VCS issues

[Ted Zlatanov]

On Thu, 28 Jan 2010 20:16:05 +0100 Florian Weimer <fw@deneb.enyo.de> wrote: 

FW> * Reiner Steib:
>> On Wed, Jan 20 2010, Adam Sjøgren wrote:
>> 
>>> What are the pros of Bazaar compared to Git?
>> 
>> Emacs uses Bazaar (mainly because it is a GNU project, see the long
>> discussions in the emacs-devel archive) and we should use the same VC
>> system as Emacs to make synching easier and so that Gnus developers
>> don't need to learn another VC system (most active Gnus developers are
>> also Emacs developers).

FW> Can Bazaar handle such cross-project merges automatically?  (AFAIK,
FW> Git's tool support for this is a bit poor.)

I don't know, but anything is better than CVS IMHO.

I haven't heard anything definitive from Lars or Reiner.  It seems like
everyone that spoke up is in favor of switching to Bazaar, though,
ranging from favorable indifference to mild approval.  Should I keep
pushing them?  I really hope this doesn't get stalled.

Ted

Re: Gnus VCS issues

[Ted Zlatanov]

On Fri, 29 Jan 2010 12:39:25 -0600 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> I haven't heard anything definitive from Lars or Reiner.  It seems like
TZ> everyone that spoke up is in favor of switching to Bazaar, though,
TZ> ranging from favorable indifference to mild approval.  Should I keep
TZ> pushing them?  I really hope this doesn't get stalled.

Reiner, Lars, are you for or against switching Gnus to Bazaar?

Note pretty much everyone, me included, is OK with Git instead of
Bazaar.  It can be synchronized with Bazaar and interfaces like Magit
make it really nice.  So really I'm pushing for a decent DVCS, although
I'd prefer Bazaar or Git over the others.

If yes to Bazaar, are you in favor of hosting with Savannah or keeping
it on gnus.org?  I assume with Git it would be hosted on gnus.org.

I really think a DVCS will improve Gnus as a project and it's a pretty
easy conversion since at least one trustworthy Git mirror exists.  It
would certainly make it easier for me personally to work more on Gnus.

We can use the Emacs conventions for ChangeLog and commit message
formatting.

Ted

Re: Gnus VCS issues

[Ted Zlatanov]

On Mon, 01 Mar 2010 00:00:40 +0100 Lars Magne Ingebrigtsen <larsi@quimbies.gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Reiner, Lars, are you for or against switching Gnus to Bazaar?
>> 
>> Note pretty much everyone, me included, is OK with Git instead of
>> Bazaar.  It can be synchronized with Bazaar and interfaces like Magit
>> make it really nice.  So really I'm pushing for a decent DVCS, although
>> I'd prefer Bazaar or Git over the others.

LMI> I'm pretty much agnostic -- I have little experience with either bzr or
LMI> git.  

My experience with Git has been more positive.  A common complaint on
the emacs-devel list is memory issues, where Bazaar baloons to hundreds
of MB, and it uses a *crazy* amount of bandwidth, also hundreds of MB
for a single pull if the commit log requires it.  There's also much more
Git knowledge and nice wrappers out there, so I say let's use Git, at
least for now.  Since there's an existing Git mirror mentioned in this
thread we can simply make a clone of it after review for consistency.

If you haven't used Git, I recommend the Magit Emacs package.  The docs
are great and it simplifies the common tasks (the
update-or-rebase->hack->stage->commit-or-ammend cycle).

>> If yes to Bazaar, are you in favor of hosting with Savannah or keeping
>> it on gnus.org?  I assume with Git it would be hosted on gnus.org.

LMI> I could give somebody (Reiner, for instance?) access to quimby.gnus.org
LMI> to install the server, if that's required.

Either Reiner or I can do it.  We should also review the list of
comitters and change their passwords as a security measure if we're
changing the server anyhow.  You or one of us can make the CVS server
read-only and keep it around, updating from Git.

The Emacs developers need to be aware of this change too so they can
pull deltas into the Emacs tree and push bugfixes back into the Gnus
tree.  I don't expect that change to be a problem.

Reiner, are you all right with this plan?  Would you like to work on
quimby or should I?

Thanks
Ted

Re: Gnus VCS issues

[Ted Zlatanov]

Ping again.  Lars, I hope you can set up a Git repo for Gnus soon.

Ted

Re: Gnus VCS issues

[Byung-Hee HWANG]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> On Wed, Jan 20 2010, Adam Sjøgren wrote:
>
>> What are the pros of Bazaar compared to Git?
>
> Emacs uses Bazaar (mainly because it is a GNU project, see the long
> discussions in the emacs-devel archive) and we should use the same VC
> system as Emacs to make synching easier and so that Gnus developers
> don't need to learn another VC system (most active Gnus developers are
> also Emacs developers).

It is reasonable, i agree with you.

> (I didn't use neither Bazaar not Git yet.)

Me, too.

Sincerely,

-- 
"It's OK with me."
		-- Virginia, "Chapter 12", page 161

Re: Gnus VCS issues

[Didier Verna]

Reiner Steib <reinersteib+gmane@imap.cc> wrote:

> On Wed, Jan 20 2010, Adam Sjøgren wrote:
>
>> What are the pros of Bazaar compared to Git?
>
> Emacs uses Bazaar (mainly because it is a GNU project, see the long
> discussions in the emacs-devel archive) and we should use the same VC
> system as Emacs to make synching easier and so that Gnus developers
> don't need to learn another VC system

  I would. I use Git for my own projects and XEmacs is under Mercurial.


> (most active Gnus developers are also Emacs developers).

  I'm not, but granted I'm not very active on Gnus either these days ;-)

-- 
Resistance is futile. You will be jazzimilated.

Scientific site:   http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com

Re: Gnus VCS issues

[Andreas Schwab]

asjo@koldfront.dk (Adam Sjøgren) writes:

> What are the pros of Bazaar compared to Git?

Tell me when you find one :-)

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Gnus VCS issues

[Miles Bader]

Andreas Schwab <schwab@linux-m68k.org> writes:
>> What are the pros of Bazaar compared to Git?
>
> Tell me when you find one :-)

Larger budget?

-miles

-- 
Bigot, n. One who is obstinately and zealously attached to an opinion that
you do not entertain.

Re: Gnus VCS issues

[David Engster]

Adam Sjøgren <asjo@koldfront.dk> writes:
> What are the pros of Bazaar compared to Git?

FWIW, there's already a git mirror at

git://randomsample.de/gnus.git (also accessible via http)

I'll try to keep that running if Gnus switches to bzr.

I'd recommend testing bzr on the Emacs repo to get an impression. It
surely is slow at the moment, but if it can deal with Emacs, it surely
can deal with Gnus. Speed issues aside, I found it pretty painless to
use for the usual day-to-day stuff.

-David

Re: Gnus VCS issues

[Adam Sjøgren]

On Thu, 21 Jan 2010 00:51:30 +0100, David wrote:

> FWIW, there's already a git mirror at

> git://randomsample.de/gnus.git (also accessible via http)

Yes, I am already using that - thanks for running it!

[...]
> Speed issues aside, I found it pretty painless to use for the usual
> day-to-day stuff.

Sounds good, thanks for the feedback.

(Git certainly seems to have the speed-thing licked pretty good).


  Best regards,

   Adam

-- 
 "But we are stubborn."                                       Adam Sjøgren
                                                         asjo@koldfront.dk

Re: Gnus VCS issues

[Miles Bader]

David Engster <deng@randomsample.de> writes:
> I'd recommend testing bzr on the Emacs repo to get an impression. It
> surely is slow at the moment, but if it can deal with Emacs, it surely
> can deal with Gnus. Speed issues aside, I found it pretty painless to
> use for the usual day-to-day stuff.

One thing that concerns me is the anti-rebasing dogma that one hears
from canonical.  Do you know if it's just dogma, or does bzr actually
have technical problems with rebasing?

[Because for the common small random commits case, it seems _much_
better to just commit to the master (i.e. trunk) branch locally and
rebase on pulling from the main repository; the "keep N branches and
merge back and forth, even for trivial commits" recipe that is
apparently advocated for emacs seems like a huge annoyance for such
trivial things.]q

-Miles

-- 
Zeal, n. A certain nervous disorder afflicting the young and inexperienced.

Re: Gnus VCS issues

[David Engster]

Miles Bader <miles@gnu.org> writes:
> David Engster <deng@randomsample.de> writes:
>> I'd recommend testing bzr on the Emacs repo to get an impression. It
>> surely is slow at the moment, but if it can deal with Emacs, it surely
>> can deal with Gnus. Speed issues aside, I found it pretty painless to
>> use for the usual day-to-day stuff.
>
> One thing that concerns me is the anti-rebasing dogma that one hears
> from canonical.  Do you know if it's just dogma, or does bzr actually
> have technical problems with rebasing?

There's a rebase plugin for bzr, so it seems technically feasible. I
didn't try it, though.

> [Because for the common small random commits case, it seems _much_
> better to just commit to the master (i.e. trunk) branch locally and
> rebase on pulling from the main repository; the "keep N branches and
> merge back and forth, even for trivial commits" recipe that is
> apparently advocated for emacs seems like a huge annoyance for such
> trivial things.]q

I agree. It all boils down to how one works with a DVCS. If you use it
in a really decentralized manner, rebasing will mess things up for
people pulling from you. However, for projects with a central
repository, with people sending patches to a maintainer, rebasing is
just the obvious thing to do (at least for me. :-) ).

-David

Re: Gnus VCS issues

[Andreas Schwab]

David Engster <deng@randomsample.de> writes:

> I agree. It all boils down to how one works with a DVCS. If you use it
> in a really decentralized manner, rebasing will mess things up for
> people pulling from you. However, for projects with a central
> repository, with people sending patches to a maintainer, rebasing is
> just the obvious thing to do (at least for me. :-) ).

This has nothing to do with distributed vs centralized, but it's all
about public vs private branches.  On a private branch you can rewrite
history as much as you like, and will generally result in a cleaner
history if done properly.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: pop3.el: Display the size of the message being fetched (POP3 LIST command)

[Ted Zlatanov]

I've comitted (finally!) this patch.  Please let me know if it causes
problems.  It's been tested by several people so I think it's fine.

Bojan, thank you for your patience.  It was my fault that it took so
long after you signed papers.

Ted