Syncing Gnus and Emacs repositories

Syncing Gnus and Emacs repositories

[Reiner Steib]

Hi,

Miles is syncing changes from Gnus repository (stable branch = v5-10)
to the Emacs trunk.

IMHO, now it would more sense to merge these changes to EMACS_22_BASE
(the 22.x release branch in Emacs' repository) instead.  Changes in
v5-10 are only bug- and doc-fixes, so we should have all these changes
in Emacs 22.2 as well.

Miles, could you arrange this (unless there are objections)?

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

Re: Syncing Gnus and Emacs repositories

[Stefan Monnier]

> Miles is syncing changes from Gnus repository (stable branch = v5-10)
> to the Emacs trunk.

> IMHO, now it would more sense to merge these changes to EMACS_22_BASE
> (the 22.x release branch in Emacs' repository) instead.  Changes in
> v5-10 are only bug- and doc-fixes, so we should have all these changes
> in Emacs 22.2 as well.

> Miles, could you arrange this (unless there are objections)?

Agreed.  And I'd also argue that the Emacs trunk version of Gnus should be
upgraded to the Gnus trunk now (and then kept in sync).


        Stefan

Re: Syncing Gnus and Emacs repositories

[Reiner Steib]

On Wed, Jun 13 2007, Stefan Monnier wrote:

>> IMHO, now it would more sense to merge these changes to EMACS_22_BASE
>> (the 22.x release branch in Emacs' repository) instead.  Changes in
>> v5-10 are only bug- and doc-fixes, so we should have all these changes
>> in Emacs 22.2 as well.
>
>> Miles, could you arrange this (unless there are objections)?
>
> Agreed.   And I'd also argue that the Emacs trunk version of Gnus should be
> upgraded to the Gnus trunk now (and then kept in sync).

Funny, that's what I suggested to Lars this morning.  ;-) But I wanted
to wait for his response before suggesting it here.

If we do this, we (Gnus developers) need to make sure to bring No Gnus
("No Gnus" = the current development version = Gnus trunk) into a
stable state in time for the feature freeze of Emacs 23.  Nobody knows
when Emacs 23 will be ready, but I think this is feasible.

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

Re: Syncing Gnus and Emacs repositories

[Stefan Monnier]

> If we do this, we (Gnus developers) need to make sure to bring No Gnus
> ("No Gnus" = the current development version = Gnus trunk) into a
> stable state in time for the feature freeze of Emacs 23.

I'd be surprised if it's not the case.  A feature freeze for Emacs-23 will
probably not happen for a while.  Several people will have to eat their
shorts if Emacs-23 comes out before 2010.


        Stefan

Re: Syncing Gnus and Emacs repositories

[Glenn Morris]

Stefan Monnier wrote:

> I'd be surprised if it's not the case.  A feature freeze for Emacs-23 will
> probably not happen for a while.  Several people will have to eat their
> shorts if Emacs-23 comes out before 2010.

(Perhaps that was reverse psychology)

Does anyone believe there is any technical reason why an Emacs 23 with
unicode and multi-tty merged in could not be released, say, within one
year?

It seems technically feasible to me (coming from a position of
ignorance), and would presumably go some way to helping restore Emacs'
reputation and relevance.

Re: Syncing Gnus and Emacs repositories

[Chong Yidong]

Glenn Morris <rgm@gnu.org> writes:

> Stefan Monnier wrote:
>
>> I'd be surprised if it's not the case.  A feature freeze for Emacs-23 will
>> probably not happen for a while.  Several people will have to eat their
>> shorts if Emacs-23 comes out before 2010.
>
> (Perhaps that was reverse psychology)
>
> Does anyone believe there is any technical reason why an Emacs 23 with
> unicode and multi-tty merged in could not be released, say, within one
> year?
>
> It seems technically feasible to me (coming from a position of
> ignorance), and would presumably go some way to helping restore Emacs'
> reputation and relevance.

If we continue to develop Emacs 23 in a spirit similar to the Emacs 22
release cycle, a 2010 release is extremely optimistic.

I, personally, would prefer a shorter release cycle for Emacs 23.  One
approach would be to limit the Emacs 23 changes to unicode, multi-tty,
and xft, with a *very* limited set of other changes.  In this
scenario, a two year cycle is feasible.

No matter which route we take, it would be nice to have some sense of
direction for Emacs 23.  Jay Belanger recently posted a message asking
about the policy for trunk development; I, too, would like to know the
answer to this.

Emacs 23 development policy (was: Syncing Gnus and Emacs repositories)

[Reiner Steib]

[ Please consider to changes the subject if the topic changes... ]

On Thu, Jun 14 2007, Chong Yidong wrote:

> I, personally, would prefer a shorter release cycle for Emacs 23.  One
> approach would be to limit the Emacs 23 changes to unicode, multi-tty,
> and xft, with a *very* limited set of other changes.  In this
> scenario, a two year cycle is feasible.

I'd suppose that several developers have uncomitted changes lying
around since the kind-of feature freeze in May 2004.  If we take "very
limited" literally, such changes might have to wait some more years.

> No matter which route we take, it would be nice to have some sense of
> direction for Emacs 23.  Jay Belanger recently posted a message asking
> about the policy for trunk development; I, too, would like to know the
> answer to this.

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

Re: Emacs 23 development policy (was: Syncing Gnus and Emacs repositories)

[David Reitter]

On 14 Jun 2007, at 07:31, Reiner Steib wrote:

> I'd suppose that several developers have uncomitted changes lying
> around since the kind-of feature freeze in May 2004.  If we take "very
> limited" literally, such changes might have to wait some more years.

There is the OpenStep/Cocoa port (Emacs.app) which was meant to be  
included. The interaction with the other code should be limited.
This port has been in development for a few years now, and it would  
probably benefit from the additional input from other developers once  
it is in the CVS (perhaps in the unicode branch to start).

Re: Emacs 23 development policy (was: Syncing Gnus and Emacs repositories)

[Adrian Robert]

On Jun 14, 2007, at 3:25 AM, David Reitter wrote:

> On 14 Jun 2007, at 07:31, Reiner Steib wrote:
>
>> I'd suppose that several developers have uncomitted changes lying
>> around since the kind-of feature freeze in May 2004.  If we take  
>> "very
>> limited" literally, such changes might have to wait some more years.
>
> There is the OpenStep/Cocoa port (Emacs.app) which was meant to be  
> included. The interaction with the other code should be limited.
> This port has been in development for a few years now, and it would  
> probably benefit from the additional input from other developers  
> once it is in the CVS (perhaps in the unicode branch to start).

As current maintainer of this port, I'll make a couple of comments here.

Back in 2004-5, I made a push to update the long-standing OpenStep  
emacs port codebase to work well on the modern Mac OS X as well as  
the open-source GNUstep API implementation.  I updated it to work  
within the character rendering framework of unicode-2 emacs, and,  
receiving some limited encouragement from this list, helped to gather  
copyright assignments from all contributors to the port past and  
present.

Late last year as I was finishing it up and getting ready to push for  
its inclusion in unicode-2, real life took over and my available time  
to work on it dropped precipitously.  Since then I have failed to  
finish it and been hesitant to push for inclusion since my ability to  
maintain it was so limited.


Here is why it should be included anyway:

- provides equal or better functionality to Carbon port on OS X,  
while also running on GNUstep open source implementation (thereby  
providing antialiased rendering on linux and similar platforms)

- high-level API allows cleaner, more compact, hopefully more  
maintainable code, a little over 1/2 #/lines of Carbon port

- if you believe high-level APIs will become more common emacs port  
targets as time goes on (GTK, etc.), this codebase provides a useful  
reference

- fully integrated in unicode-2 branch, using new font backend and  
unicode representation throughout the rendering pipeline


Here is why it should NOT be included:

- I lack the time to maintain it, and for whatever reason so far,  
interest by other developers has been limited

- it still needs work: compositional character rendering, menu option  
display, some rendering and font-selection bugs

- the actively-maintained Carbon port already provides OS X  
functionality, and GNUstep's relevance is questionable


Anyway, there you have it.  If it ends up there is interest in its  
inclusion, and the promise of other maintainers besides myself, I'll  
work on the remaining issues with the port in August, deal with  
integration issues, and provide guidance on the code.  Either way, it  
will continue to be available at http://emacs-app.sf.net/

Sorry for the long message, please cc me with any replies, thanks.

Adrian

Re: Emacs 23 development policy

[Stefan Monnier]

Regarding the Cocoa/GNUstep port, I have no first-hand knowledge of its
code/features/etc... but from what I hear, I am of the opinion that it
should eventually replace the current Carbon port.  If that's indeed the
case, than we should merge it in as soon as possible.
The prerequistes seem to be (for me):

1 - it works enough to be usable to do work such as porting and debugging.
    This is important to make sure people interested in this port will be
    sufficiently motivated.
2 - its inclusion is properly protected by the relevant #ifdefs such that it
    obviously does not impact the stability of existing code and features.
3 - the code isn't made up of temporary ugly hacks.

>From what you say, it seems like the code shouldn't be too far from this state.
Now, of course maybe others will disagree on my conditions and will want to
be more stringent.


        Stefan

Re: Syncing Gnus and Emacs repositories

[Richard Stallman]

    No matter which route we take, it would be nice to have some sense of
    direction for Emacs 23.  Jay Belanger recently posted a message asking
    about the policy for trunk development; I, too, would like to know the
    answer to this.

I said weeks ago people can install new features in the trunk now.
What uncertainty remains?

Re: Syncing Gnus and Emacs repositories

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     No matter which route we take, it would be nice to have some sense of
>     direction for Emacs 23.  Jay Belanger recently posted a message asking
>     about the policy for trunk development; I, too, would like to know the
>     answer to this.
>
> I said weeks ago people can install new features in the trunk now.
> What uncertainty remains?

Did you mean, everything except the unicode code?

Re: Syncing Gnus and Emacs repositories

[Kenichi Handa]

In article <87lkemmrg4.fsf@stupidchicken.com>, Chong Yidong <cyd@stupidchicken.com> writes:

> Richard Stallman <rms@gnu.org> writes:
> >     No matter which route we take, it would be nice to have some sense of
> >     direction for Emacs 23.  Jay Belanger recently posted a message asking
> >     about the policy for trunk development; I, too, would like to know the
> >     answer to this.
> >
> > I said weeks ago people can install new features in the trunk now.
> > What uncertainty remains?

> Did you mean, everything except the unicode code?

Please postpone installing heavy changes of C code
(including cosmetic ones) until emacs-unicode-2 is merged
into the trunk unless you take care of the confliction
caused by the merging of them into emacs-unicode-2 branch
(that merging is done periodically).  You also have to take
care of new codes added in emacs-unicode-2 if the change
must be applied to many files systematically.

---
Kenichi Handa
handa@m17n.org

Re: Syncing Gnus and Emacs repositories

[Miles Bader]

Kenichi Handa <handa@m17n.org> writes:
>> Did you mean, everything except the unicode code?
>
> Please postpone installing heavy changes of C code
> (including cosmetic ones) until emacs-unicode-2 is merged
> into the trunk unless you take care of the confliction
> caused by the merging of them into emacs-unicode-2 branch
> (that merging is done periodically).

BTW, I'm going on a long vacation next monday, so won't
be doing any syncing between 18-June and 7-July.

I will try to make everything up-to-date this weekend before I leave
though.

-Miles

-- 
Come now, if we were really planning to harm you, would we be waiting here,
 beside the path, in the very darkest part of the forest?

Re: Syncing Gnus and Emacs repositories

[Kenichi Handa]

In article <buod4zyrn2x.fsf@dhapc248.dev.necel.com>, Miles Bader <miles.bader@necel.com> writes:

> Kenichi Handa <handa@m17n.org> writes:
>>> Did you mean, everything except the unicode code?
> >
> > Please postpone installing heavy changes of C code
> > (including cosmetic ones) until emacs-unicode-2 is merged
> > into the trunk unless you take care of the confliction
> > caused by the merging of them into emacs-unicode-2 branch
> > (that merging is done periodically).

> BTW, I'm going on a long vacation next monday, so won't
> be doing any syncing between 18-June and 7-July.

I envy you.  :-)  Have a nice vacation!

> I will try to make everything up-to-date this weekend before I leave
> though.

Thank you.

---
Kenichi Handa
handa@m17n.org

Re: Syncing Gnus and Emacs repositories

[Nick Roberts]

 > > >     No matter which route we take, it would be nice to have some sense
 > > >     of direction for Emacs 23.  Jay Belanger recently posted a message
 > > >     asking about the policy for trunk development; I, too, would like to
 > > >     know the answer to this.
 > > >
 > > > I said weeks ago people can install new features in the trunk now.
 > > > What uncertainty remains?
 > 
 > > Did you mean, everything except the unicode code?
 > 
 > Please postpone installing heavy changes of C code
 > (including cosmetic ones) until emacs-unicode-2 is merged
 > into the trunk unless you take care of the confliction
 > caused by the merging of them into emacs-unicode-2 branch
 > (that merging is done periodically).  You also have to take
 > care of new codes added in emacs-unicode-2 if the change
 > must be applied to many files systematically.

Surely emacs-unicode-2 should be the _next_ thing to be merged to the trunk, if
only because it's existed as a branch for three years now (multi-tty is a
relative newcomer on that basis).  It seems unreasonable, to me, to expect
Kenichi to merge changes indefinitely.

I don't think there are enough resources to keep maintaining all these
different branches for very long.  In any case, it must be quite likely that
there will just be bugfix-like releases from EMACS_22_BASE (just as there were
from EMACS_21_1_RC).

And let's make that merge now, before we slip (further) into oblivion.

-- 
Nick                                            http://www.inet.net.nz/~nickrob

Re: Syncing Gnus and Emacs repositories

[Richard Stallman]

I have decided that we should not merge unicode-2 until a couple of
months have gone by and we know what should be done about Emacs 22.2.
Until then I want to avoid far-reaching changes in the trunk.
Please stop making a fuss about a couple of months.

However, it is ok to add new features which are not so far-reaching in
their effects on the code.  Even the multi-tty branch could be merged
in (once we decide what to do about the environment).

Re: Syncing Gnus and Emacs repositories

[Nick Roberts]

 > I have decided that we should not merge unicode-2 until a couple of
 > months have gone by and we know what should be done about Emacs 22.2.
 > Until then I want to avoid far-reaching changes in the trunk.
 > Please stop making a fuss about a couple of months.

You might perceive it to be a fuss but a couple of months will probably end up
being four or five, evidently there are other things planned, like the cocoa
port, then there will probably be a period of instability, new documentation
will be needed...whoa it's 2010!

Many people who offered contributions over the last couple of years were told
to come back after the release.  Maybe some will, but I think we're losing
leverage.  Also I think being out of the picture for so long means we lose
mindshare, get dropped from the desktop etc., but perhaps your view is that
quality is the only thing that matters.

 > However, it is ok to add new features which are not so far-reaching in
 > their effects on the code.  Even the multi-tty branch could be merged
 > in (once we decide what to do about the environment).

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Syncing Gnus and Emacs repositories

[Richard Stallman]

    You might perceive it to be a fuss but a couple of months will probably end up
    being four or five,

It is not impossible, but even so, that is not a very long long time.

			evidently there are other things planned, like the cocoa
    port,

There are many changes people are thinking of installing.  But that's
an unrelated issue.  They will take time, whether we start now or in August.

     then there will probably be a period of instability, new documentation
    will be needed...whoa it's 2010!

If you think that the rest of the work will take 3 years, why fuss
about two months more or less?

I've told you my decision.

Re: Syncing Gnus and Emacs repositories

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>      then there will probably be a period of instability, new documentation
>     will be needed...whoa it's 2010!
>
> If you think that the rest of the work will take 3 years, why fuss
> about two months more or less?

The point is that there's no perceptible benefit to waiting two
months.

Re: Syncing Gnus and Emacs repositories

[David Kastrup]

Chong Yidong <cyd@stupidchicken.com> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>>      then there will probably be a period of instability, new documentation
>>     will be needed...whoa it's 2010!
>>
>> If you think that the rest of the work will take 3 years, why fuss
>> about two months more or less?
>
> The point is that there's no perceptible benefit to waiting two
> months.

Another would be that the 3 years are a _consequence_ of lots of such
two-month delays.

It's like saying it is ok to jump out of the window since smashing
into the ground at high speed will hurt, anyway, regardless of whether
one jumped out of the window or not.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Syncing Gnus and Emacs repositories

[Richard Stallman]

    It's like saying it is ok to jump out of the window since smashing
    into the ground at high speed will hurt, anyway, regardless of whether
    one jumped out of the window or not.

Absurd attacks like this are no reason for me to reconsider my
decision.  They do make me angry with you.

Re: Syncing Gnus and Emacs repositories

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     It's like saying it is ok to jump out of the window since smashing
>     into the ground at high speed will hurt, anyway, regardless of whether
>     one jumped out of the window or not.
>
> Absurd attacks like this are no reason for me to reconsider my
> decision.  They do make me angry with you.

The problem is that the argument "if all our delays of several months
add up to several years, a delay of several months does no significant
harm" is equally absurd.  Which makes me angry.  That the same twisted
logic makes you angry as well should not come as much of a surprise.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Syncing Gnus and Emacs repositories

[Richard Stallman]

    The point is that there's no perceptible benefit to waiting two
    months.

You may not see it, but what can I do about that?

Re: Syncing Gnus and Emacs repositories

[Kenichi Handa]

In article <E1HzqWo-0001dR-GS@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:

>     The point is that there's no perceptible benefit to waiting two
>     months.

> You may not see it, but what can I do about that?

I don't see it either.  I may have missed your mail writing
it.  Could you please explain what is the purpose of waiting
for more months again?

---
Kenichi Handa
handa@m17n.org

Re: Syncing Gnus and Emacs repositories

[Richard Stallman]

    I don't see it either.  I may have missed your mail writing
    it.  Could you please explain what is the purpose of waiting
    for more months again?

So that it won't be hard to transfer changes between the trunk
and EMACS_22_BASE, for the next month or so.

Re: Syncing Gnus and Emacs repositories

[Kenichi Handa]

In article <E1I0OoJ-00086U-3O@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:

>     I don't see it either.  I may have missed your mail writing
>     it.  Could you please explain what is the purpose of waiting
>     for more months again?

> So that it won't be hard to transfer changes between the trunk
> and EMACS_22_BASE, for the next month or so.

Ok, I now see your intention.  I've thought that Emacs 22.2,
3, ... are just bug-fix releases, but it seems that new
features will also go to Emacs 22.2, right?

I'm afraid that it resembles to the situation when it was
decided that we release Emacs 22.1 without Unicode patch
instead of Emacs 21.5, and even after that, new features
were continuously added for Emacs 22.1.

When are you going to declare feature freeze for Emacs 22.2?

---
Kenichi Handa
handa@m17n.org

Re: Syncing Gnus and Emacs repositories

[Stefan Monnier]

> When are you going to declare feature freeze for Emacs 22.2?

The way I'd like to see it, we'd allow package addition (e.g. css-mode) and
other similar changes that "cannot add bugs in the existing features".
We still want to be careful with such additions since they need to be
sufficiently bug-free not to slow down the release process.

I feel like such additions are important for the morale of external
contributors who'd rather not have to wait 3 or more years until their
contributed package appears in a release.

This said, such additions are inherently orthogonal to the unicode merge
(because if they depend on the unicode merge, it means it's too delicate
a package to deserve inclusion in the release branch), so merging unicode
right now would not make it harder to backport such new packages to the
release branch.

I.e. I'm in favor of merging the unicode branch as soon as possible.


        Stefan

Re: Syncing Gnus and Emacs repositories

[Richard Stallman]

    Ok, I now see your intention.  I've thought that Emacs 22.2,
    3, ... are just bug-fix releases, but it seems that new
    features will also go to Emacs 22.2, right?

A few modular new features can be put in Emacs 22, if they
are totally safe.  However, in general, new features should
only be put in Emacs 23 (trunk and unicode-2) and not in Emacs 22.

Re: Syncing Gnus and Emacs repositories

[Kenichi Handa]

In article <E1I0m9t-0000vO-L3@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:

>     Ok, I now see your intention.  I've thought that Emacs 22.2,
>     3, ... are just bug-fix releases, but it seems that new
>     features will also go to Emacs 22.2, right?

> A few modular new features can be put in Emacs 22, if they
> are totally safe.  However, in general, new features should
> only be put in Emacs 23 (trunk and unicode-2) and not in Emacs 22.

Ummm, I hope such a new feature addition doesn't reveal a bug of
Emacs 22 that is already fixed (or can be fixed more
cleanly) in Emacs 23.  In such a case, please just cancel
that addition and add it in emacs-unicode-2.

---
Kenichi Handa
handa@m17n.org

Re: Syncing Gnus and Emacs repositories

[Richard Stallman]

    > A few modular new features can be put in Emacs 22, if they
    > are totally safe.  However, in general, new features should
    > only be put in Emacs 23 (trunk and unicode-2) and not in Emacs 22.

    Ummm, I hope such a new feature addition doesn't reveal a bug of
    Emacs 22 that is already fixed (or can be fixed more
    cleanly) in Emacs 23.  In such a case, please just cancel
    that addition and add it in emacs-unicode-2.

I agree.

Re: Syncing Gnus and Emacs repositories

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> I have decided that we should not merge unicode-2 until a couple of
> months have gone by and we know what should be done about Emacs
> 22.2.

But Emacs 22.2 will be released from EMACS_22_BASE.  It does not
depend on the trunk.  The whole point of forking a release branch was
to be able to move forward again in the trunk.

> Until then I want to avoid far-reaching changes in the trunk.

Why?  The trunk is not what is going to end up in Emacs 22.2.  The
target of the trunk is to move towards 23.1 (and then later versions).

> Please stop making a fuss about a couple of months.

It just appears quite pointless to be driving with the handbrake on
after we passed the point of the release.

> However, it is ok to add new features which are not so far-reaching
> in their effects on the code.  Even the multi-tty branch could be
> merged in (once we decide what to do about the environment).

It is fine if we have a plan what kind of work to do in what manner,
and then concentrate on accomplishing it.

The current plan, however, seems to be "let's achieve as little as
possible over as long as possible".  You call for several months of
delay until "we know what should be done about Emacs 22.2".  But this
knowledge will not drop from the skies while we are idling.  It can
only come about by people _working_ on the trunk with _several_
features so that it becomes clear which of these features (if any) are
suitably fit for merging into EMACS_22_BASE (and consequently will
appear in 22.2), and which aren't.

The way to find that out is hardly by doing nothing until
enlightenment strikes us.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Syncing Gnus and Emacs repositories

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Sat, 16 Jun 2007 00:12:56 +0200
> Cc: rgm@gnu.org, handa@m17n.org, Nick Roberts <nickrob@snap.net.nz>,
> 	emacs-devel@gnu.org, monnier@iro.umontreal.ca, cyd@stupidchicken.com
> 
> It just appears quite pointless to be driving with the handbrake on
> after we passed the point of the release.

I don't necessarily agree with Richard's decision, but can you explain
why should it be a drag on the development?  If someone wants to make
far-reaching changes, they could always switch to the Unicode branch
and make them there, can't they?

Also, please note that it was Ken'ichi who asked not to make changes
on the trunk that would make it harder to merge the Unicode branch;
if you want to be fair, why don't you lobby Ken'ichi as hard as you
lobby Richard?

> The current plan, however, seems to be "let's achieve as little as
> possible over as long as possible".

That's just being vicious, David.  There are ways to say what you want
without assuming malicious intent such as this, which Richard clearly
cannot have.

Re: Syncing Gnus and Emacs repositories

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Sat, 16 Jun 2007 00:12:56 +0200
>> Cc: rgm@gnu.org, handa@m17n.org, Nick Roberts <nickrob@snap.net.nz>,
>> 	emacs-devel@gnu.org, monnier@iro.umontreal.ca, cyd@stupidchicken.com
>> 
>> It just appears quite pointless to be driving with the handbrake on
>> after we passed the point of the release.
>
> I don't necessarily agree with Richard's decision, but can you
> explain why should it be a drag on the development?  If someone
> wants to make far-reaching changes, they could always switch to the
> Unicode branch and make them there, can't they?

And that is going to make merging unicode-2 into the trunk easier just
how?  And if we are considering new feature branches, should they be
based off unicode-2 in order to have the ability to prepare stuff
intended for 23.1?

> Also, please note that it was Ken'ichi who asked not to make changes
> on the trunk that would make it harder to merge the Unicode branch;
> if you want to be fair, why don't you lobby Ken'ichi as hard as you
> lobby Richard?

Why would I?  What is the plan for the trunk?  The two opinions
here are:

Richard) Let's keep the trunk close to 22.1

Ken'ichi) Let's keep the trunk close to unicode-2 so that we can move
          forward soon with merging, and don't have extra effort to
          move Emacs to 23.1.

The difference is that I see no useful "so that" for Richard's desire.
The direction of development should be forward, not backward.

Would Ken'ichi complain if we merged unicode-2 into the trunk
tomorrow?  I doubt it.  There is a _purpose_ to Ken'ichi's request,
and that purpose is to facilitate move development forward.

I fail to see a similar purpose to the request of Richard.

>> The current plan, however, seems to be "let's achieve as little as
>> possible over as long as possible".
>
> That's just being vicious, David.  There are ways to say what you
> want without assuming malicious intent such as this, which Richard
> clearly cannot have.

I don't see where I am stating malicious intent here.  It is quite
obvious that Richard does not consider a stop of development a bad
thing, or he would hardly argue for it.

I consider it a bad thing, actually a very, very, very bad thing: now
that Emacs has come a bit up on the radar of media and user attention,
the main message to be gleaned from the developer lists is that we
actively refrain from using that opportunity to have the glacial
development of Emacs pick off.  Worse, people are discouraged from
thinking about the next release: instead it is mandated that we stop
development for "a few months".  One of the points of branching
EMACS_22_BASE and making the 22.1 release was to be able to move
forward again after _years_ of stalling and freezing for "a few
months".

If I were of the opinion that Richard was being malicious, I would not
argue with him.  In his political work, he is thinking and working in
time frames of decades and lifetimes: that is the scale at which
shaping the flow of global thinking takes place.  Opportunities for
changing the twist and turns of humanity are rare to come by.

The flow of coding is that going on in spurts at night and on
weekends.  Opportunities for changing the twist and turns of program
code arise and fall by the wayside daily.

Pausing for several months for no discernible reason is _costly_ in
programming, in particular in a distributed project.  In politics,
that is the normal state of affairs.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Syncing Gnus and Emacs repositories

[Eli Zaretskii]

> Cc: rms@gnu.org,  emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Sat, 16 Jun 2007 14:09:54 +0200
> 
> > I don't necessarily agree with Richard's decision, but can you
> > explain why should it be a drag on the development?  If someone
> > wants to make far-reaching changes, they could always switch to the
> > Unicode branch and make them there, can't they?
> 
> And that is going to make merging unicode-2 into the trunk easier just
> how?

It won't make it easier, but I don't see how it would make it harder,
either.

> And if we are considering new feature branches

Are we? if so, what are they?  If this is just a hypothetical
situation, we don't need to be bothered by it.

> should they be based off unicode-2 in order to have the ability to
> prepare stuff intended for 23.1?

It depends on the specific feature in question.

> Richard) Let's keep the trunk close to 22.1
> 
> Ken'ichi) Let's keep the trunk close to unicode-2 so that we can move
>           forward soon with merging, and don't have extra effort to
>           move Emacs to 23.1.
> 
> The difference is that I see no useful "so that" for Richard's desire.

I don't see how that matters.  It is the combination of these that
causes the development to stall; take out one of them, and the problem
is gone.

> Would Ken'ichi complain if we merged unicode-2 into the trunk
> tomorrow?  I doubt it.

He asked not to, so doing so over his objections would be unkind.

> There is a _purpose_ to Ken'ichi's request,
> and that purpose is to facilitate move development forward.
> 
> I fail to see a similar purpose to the request of Richard.

This just means that you agree with Ken'ichi, but not with Richard.
But compromises are not based on agreements, they are based on meeting
your opponents half-way.

> >> The current plan, however, seems to be "let's achieve as little as
> >> possible over as long as possible".
> >
> > That's just being vicious, David.  There are ways to say what you
> > want without assuming malicious intent such as this, which Richard
> > clearly cannot have.
> 
> I don't see where I am stating malicious intent here.

Then perhaps we have very different standards of civilized behavior,
and continuing this discussion becomes useless and pointless.

Re: Syncing Gnus and Emacs repositories

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

[...]

>> Would Ken'ichi complain if we merged unicode-2 into the trunk
>> tomorrow?  I doubt it.
>
> He asked not to, so doing so over his objections would be unkind.

Frankly, I don't see the point in not merging either.  I don't see
that the trunk accomplishes _any_ function in connection to Emacs
development that would not equally well be accomplished if unicode-2
was merged.  We don't need a "stable" trunk: we have EMACS_BASE_22 for
that purpose.

Our goal, in my opinion, should never become to have the trunk be the
main distribution channel of Emacs (as it has been for some years).

> This just means that you agree with Ken'ichi, but not with Richard.
> But compromises are not based on agreements, they are based on
> meeting your opponents half-way.

So why are you concerned about my disagreement if agreement is not
important to you?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Syncing Gnus and Emacs repositories

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Sat, 16 Jun 2007 15:13:40 +0200
> 
> So why are you concerned about my disagreement if agreement is not
> important to you?

Because I'm trying to reach a compromise.

Re: Syncing Gnus and Emacs repositories

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: emacs-devel@gnu.org
>> From: David Kastrup <dak@gnu.org>
>> Date: Sat, 16 Jun 2007 15:13:40 +0200
>> 
>> So why are you concerned about my disagreement if agreement is not
>> important to you?
>
> Because I'm trying to reach a compromise.

For better or worse, the decisions are made by Richard, and Richard
alone.  Agreement on the developer list, as you astutely remarked, is
irrelevant.  Any mediation or compromising concerning the development
goals and directions is the task of Richard or whoever else happens to
be the project leader, based on the input and feedback on the list.

A "compromise" where one side's obligation is just to keep quiet about
what it considers a bad idea is not, as far as I can see, conducive to
making progress.

Anyway, could you spell out the details of the compromise you are
trying to reach?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Syncing Gnus and Emacs repositories

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Sat, 16 Jun 2007 16:05:16 +0200
> 
> Anyway, could you spell out the details of the compromise you are
> trying to reach?

I would like to find a way for the development to continue without
interfering with Richard's goals.  Using the Unicode branch for
development sounds like a good candidate for that; you didn't yet say
anything that would invalidate it.

Re: Syncing Gnus and Emacs repositories

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: emacs-devel@gnu.org
>> From: David Kastrup <dak@gnu.org>
>> Date: Sat, 16 Jun 2007 16:05:16 +0200
>> 
>> Anyway, could you spell out the details of the compromise you are
>> trying to reach?
>
> I would like to find a way for the development to continue without
> interfering with Richard's goals.

Shouldn't this be rather "Richard's concepts"?  The continuation of
development should hardly interfere with Richard's _goals_.

> Using the Unicode branch for development sounds like a good
> candidate for that; you didn't yet say anything that would
> invalidate it.

It did not really come up.  So let me comment on it now: the problem I
see with that idea is that after the unicode-2/trunk merge, there will
be lots of areas where people and their favorite private packages will
get exposure to the unicode-2 internals the first time, and there will
be lots of problems to shake out.  If the merge consisted of just such
differences as can be contributed to the changed representation of the
multibyte strings and buffers, shaking out the problems encountered in
the process will be much easier if the branch has been kept reasonably
clean of unrelated changes and developments.

Basically your approach sounds to me like "let us make unicode-2 our
new trunk and work around Richard in that manner".  But one can't hope
to have something like that work consistently, and so some additions
will happen to unicode-2, and some to the trunk, and there will be a
lot of merge mess in two directions for which I see little motivation
and which actually is quite painful in CVS.

There is something to be said for the decentralized Linux kernel
source code management system git: basically, everybody pieces
together his favorite patches and branches, and merging is something
which everybody can do or let alone at his own leisure in his own
repository.  Interesting functionality is circulated as "patch sets",
and if one's personal branch has repeated conflicts with patch sets
from different branches, one can automate the conflict resolution
since git also keeps track of previous conflict resolutions.  It is
also easy to back out change sets again, even after one has had
conflict resolution.  I'll append a manual page for one particular
tool of its toolset.  It really is interesting.

But at the moment, we are using CVS, and everybody's trunk is the
same, and managed on Savannah instead of locally.  And that will
influence how people will treat it and work with it.  Distributing new
development among trunk and multitty and hoping that Miles and
Handa-san will sort out the mess for "a few months" more is not really
efficient if there is no particular goal achieved by that.

It is dealing with a code management problem by technical means,
expedience and additional manual work.  With good tools, the
additional manual work becomes less, but with our current setup I
think it problematic enough not to shrug it off lightly.

Of course, engaging people in shouting matches is also not efficient
use of their time.  There will be a time when I stop tearing my hairs
out publically when it turns out that I am not able to get my point
across, anyway.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

GIT-RERERE(1)                                                    GIT-RERERE(1)

NAME
       git-rerere - Reuse recorded resolve

SYNOPSIS
       git-rerere.sp

DESCRIPTION
       In a workflow that employs relatively long lived topic branches, the
       developer sometimes needs to resolve the same conflict over and over
       again until the topic branches are done (either merged to the "release"
       branch, or sent out and accepted upstream)..sp This command helps this
       process by recording conflicted automerge results and corresponding
       hand-resolve results on the initial manual merge, and later by noticing
       the same automerge results and applying the previously recorded hand
       resolution..sp

       Note
       You need to create $GIT_DIR/rr-cache directory to enable this
       command..sp

DISCUSSION
       When your topic branch modifies overlapping area that your master
       branch (or upstream) touched since your topic branch forked from it,
       you may want to test it with the latest master, even before your topic
       branch is ready to be pushed upstream:.sp

                        o---*---o topic
                       /
              o---o---o---*---o---o master
       For such a test, you need to merge master and topic somehow. One way to
       do it is to pull master into the topic branch:.sp

                  $ git checkout topic
                  $ git pull . master

                        o---*---o---+ topic
                       /           /
              o---o---o---*---o---o master
       The commits marked with * touch the same area in the same file; you
       need to resolve the conflicts when creating the commit marked with +.
       Then you can test the result to make sure your work-in-progress still
       works with what is in the latest master..sp After this test merge,
       there are two ways to continue your work on the topic. The easiest is
       to build on top of the test merge commit +, and when your work in the
       topic branch is finally ready, pull the topic branch into master,
       and/or ask the upstream to pull from you. By that time, however, the
       master or the upstream might have been advanced since the test merge +,
       in which case the final commit graph would look like this:.sp

                  $ git checkout topic
                  $ git pull . master
                  $ ... work on both topic and master branches
                  $ git checkout master
                  $ git pull . topic

                        o---*---o---+---o---o topic
                       /           /         \
              o---o---o---*---o---o---o---o---+ master
       When your topic branch is long-lived, however, your topic branch would
       end up having many such "Merge from master" commits on it, which would
       unnecessarily clutter the development history. Readers of the Linux
       kernel mailing list may remember that Linus complained about such too
       frequent test merges when a subsystem maintainer asked to pull from a
       branch full of "useless merges"..sp As an alternative, to keep the
       topic branch clean of test merges, you could blow away the test merge,
       and keep building on top of the tip before the test merge:.sp

                  $ git checkout topic
                  $ git pull . master
                  $ git reset --hard HEAD^ ;# rewind the test merge
                  $ ... work on both topic and master branches
                  $ git checkout master
                  $ git pull . topic

                        o---*---o-------o---o topic
                       /                     \
              o---o---o---*---o---o---o---o---+ master
       This would leave only one merge commit when your topic branch is
       finally ready and merged into the master branch. This merge would
       require you to resolve the conflict, introduced by the commits marked
       with *. However, often this conflict is the same conflict you resolved
       when you created the test merge you blew away. git-rerere command helps
       you to resolve this final conflicted merge using the information from
       your earlier hand resolve..sp Running git-rerere command immediately
       after a conflicted automerge records the conflicted working tree files,
       with the usual conflict markers <<<<<<<, =======, and >>>>>>> in them.
       Later, after you are done resolving the conflicts, running git-rerere
       again records the resolved state of these files. Suppose you did this
       when you created the test merge of master into the topic branch..sp
       Next time, running git-rerere after seeing a conflicted automerge, if
       the conflict is the same as the earlier one recorded, it is noticed and
       a three-way merge between the earlier conflicted automerge, the earlier
       manual resolution, and the current conflicted automerge is performed by
       the command. If this three-way merge resolves cleanly, the result is
       written out to your working tree file, so you would not have to
       manually resolve it. Note that git-rerere leaves the index file alone,
       so you still need to do the final sanity checks with git diff (or git
       diff -c) and git update-index when you are satisfied..sp As a
       convenience measure, git-merge automatically invokes git-rerere when it
       exits with a failed automerge, which records it if it is a new
       conflict, or reuses the earlier hand resolve when it is not. git-commit
       also invokes git-rerere when recording a merge result. What this means
       is that you do not have to do anything special yourself (Note: you
       still have to create $GIT_DIR/rr-cache directory to enable this
       command)..sp In our example, when you did the test merge, the manual
       resolution is recorded, and it will be reused when you do the actual
       merge later with updated master and topic branch, as long as the
       earlier resolution is still applicable..sp The information git-rerere
       records is also used when running git-rebase. After blowing away the
       test merge and continuing development on the topic branch:.sp

                        o---*---o-------o---o topic
                       /
              o---o---o---*---o---o---o---o   master

                  $ git rebase master topic

                                            o---*---o-------o---o topic
                                           /
              o---o---o---*---o---o---o---o   master
       you could run git rebase master topic, to keep yourself up-to-date even
       before your topic is ready to be sent upstream. This would result in
       falling back to three-way merge, and it would conflict the same way the
       test merge you resolved earlier. git-rerere is run by git rebase to
       help you resolve this conflict..sp

AUTHOR
       Written by Junio C Hamano <junkio@cox.net>.sp

GIT
       Part of the git(7) suite.sp

                                  03/05/2007                     GIT-RERERE(1)

Re: Syncing Gnus and Emacs repositories

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Sat, 16 Jun 2007 19:38:36 +0200
> 
> the problem I
> see with that idea is that after the unicode-2/trunk merge, there will
> be lots of areas where people and their favorite private packages will
> get exposure to the unicode-2 internals the first time, and there will
> be lots of problems to shake out.  If the merge consisted of just such
> differences as can be contributed to the changed representation of the
> multibyte strings and buffers, shaking out the problems encountered in
> the process will be much easier if the branch has been kept reasonably
> clean of unrelated changes and developments.
> 
> Basically your approach sounds to me like "let us make unicode-2 our
> new trunk and work around Richard in that manner".  But one can't hope
> to have something like that work consistently, and so some additions
> will happen to unicode-2, and some to the trunk, and there will be a
> lot of merge mess in two directions for which I see little motivation
> and which actually is quite painful in CVS.

Basically, you say this will somewhat less convenient.  Yes, it will,
but not by a large margin.  I don't think we cannot afford the small
measure of inconvenience.

Re: Syncing Gnus and Emacs repositories

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 16 Jun 2007 15:13:40 +0200, David Kastrup <dak@gnu.org> said:

> Frankly, I don't see the point in not merging either.  I don't see
> that the trunk accomplishes _any_ function in connection to Emacs
> development that would not equally well be accomplished if unicode-2
> was merged.  We don't need a "stable" trunk: we have EMACS_BASE_22
> for that purpose.

I had an impression (yes, just an impression) that:

  EMACS_BASE_22: to become the next bugfix release 22.2.
    Only bugfix changes should go there.
  trunk: to become EMACS_BASE_22 after the 22.2 release.
    Changes common to 22 and 23 should go there.
  emacs-unicode-2: to become the trunk after the 22.2 release.
    Changes specific to 23 (but not multi-tty-specific) should go there.
    Changes made to the trunk also go there by regular sync. by Miles.

But as Richard said multi-tty changes could also go to the trunk under
a certain condition, this impression will never be true at least in a
strict sense.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Syncing Gnus and Emacs repositories

[David Kastrup]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

>>>>>> On Sat, 16 Jun 2007 15:13:40 +0200, David Kastrup <dak@gnu.org> said:
>
>> Frankly, I don't see the point in not merging either.  I don't see
>> that the trunk accomplishes _any_ function in connection to Emacs
>> development that would not equally well be accomplished if unicode-2
>> was merged.  We don't need a "stable" trunk: we have EMACS_BASE_22
>> for that purpose.
>
> I had an impression (yes, just an impression) that:
>
>   EMACS_BASE_22: to become the next bugfix release 22.2.
>     Only bugfix changes should go there.

Pretty much the point, though it is not clear whether some other
stuff, like package updates will happen there, too.

>   trunk: to become EMACS_BASE_22 after the 22.2 release.

That would make no sense.  The point of the branch was to get a stable
basis.

>     Changes common to 22 and 23 should go there.

Frankly, I don't see that we can afford separate 22.x and 23.x
development lines.

>   emacs-unicode-2: to become the trunk after the 22.2 release.
>   Changes specific to 23 (but not multi-tty-specific) should go
>   there.  Changes made to the trunk also go there by regular
>   sync. by Miles.
>
> But as Richard said multi-tty changes could also go to the trunk
> under a certain condition, this impression will never be true at
> least in a strict sense.

At the risk of repeating myself: active branches are expensive with
regard to developer mindframe and feature availability (having the
features of more than a single branch lets the merge efforts explode
exponentially).

We should clamp down on active branches whenever we can.  If two
active branches have no separate release goals, maintaining them
separately is a cost in complexity and mindshare that we should not be
affording without very good reason.  EMACS_22_BASE is for 22.x,
unicode-2 is clearly for 23.x, trunk has no clear release goal
whatsoever.

Branches and functionality like antialiasing, xft, bidi and others
don't make much sense basing off or synching with a non-unicode-2
trunk.  Neither does it make much sense to add new input encodings and
similar stuff that is likely to interact with unicode-2 differently
than with Emacs 22.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Syncing Gnus and Emacs repositories

[Kenichi Handa]

In article <uodjgrr33.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> > Would Ken'ichi complain if we merged unicode-2 into the trunk
> > tomorrow?  I doubt it.

> He asked not to, so doing so over his objections would be unkind.

No.  I asked to merge unicode-2 into the trunk, but as it
was not accepted, I asked not to make heavy changes to the
trunk unless one takes care of emacs-unicode-2 branch too.

---
Kenichi Handa
handa@m17n.org

Re: Syncing Gnus and Emacs repositories

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> CC: dak@gnu.org, emacs-devel@gnu.org
> Date: Mon, 18 Jun 2007 08:07:28 +0900
> 
> No.  I asked to merge unicode-2 into the trunk, but as it
> was not accepted, I asked not to make heavy changes to the
> trunk unless one takes care of emacs-unicode-2 branch too.

So in that case, making such changes in the Unicode branch directly,
as I suggested, would be a good way of installing changes without
interfering with the future merge, right?

Re: Syncing Gnus and Emacs repositories

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Kenichi Handa <handa@m17n.org>
>> CC: dak@gnu.org, emacs-devel@gnu.org
>> Date: Mon, 18 Jun 2007 08:07:28 +0900
>> 
>> No.  I asked to merge unicode-2 into the trunk, but as it
>> was not accepted, I asked not to make heavy changes to the
>> trunk unless one takes care of emacs-unicode-2 branch too.
>
> So in that case, making such changes in the Unicode branch directly,
> as I suggested, would be a good way of installing changes without
> interfering with the future merge, right?

Could you explain how putting _unrelated_ changes into the Unicode
branch would not interfere with a merge?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Syncing Gnus and Emacs repositories

[Nick Roberts]

 > >> No.  I asked to merge unicode-2 into the trunk, but as it
 > >> was not accepted, I asked not to make heavy changes to the
 > >> trunk unless one takes care of emacs-unicode-2 branch too.
 > >
 > > So in that case, making such changes in the Unicode branch directly,
 > > as I suggested, would be a good way of installing changes without
 > > interfering with the future merge, right?
 > 
 > Could you explain how putting _unrelated_ changes into the Unicode
 > branch would not interfere with a merge?

It makes sense to me: if most changes are in the Unicode branch then if you
view it as merging the trunk to the branch, fewer changes need to be made.

However, it might be a problem if the changes on the branch break things.  So
it might be a good idea to branch the branch or at least tag it first as a
possible future branchpoint.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Syncing Gnus and Emacs repositories

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Mon, 18 Jun 2007 18:01:24 +1200
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org,
> 	Kenichi Handa <handa@m17n.org>
> 
> However, it might be a problem if the changes on the branch break
> things.

If they break the Unicode branch, they will break the trunk when the
Unicode branch is merged into it.  So I see no disadvantage here.

Re: Syncing Gnus and Emacs repositories

[Nick Roberts]

 > > However, it might be a problem if the changes on the branch break
 > > things.
 > 
 > If they break the Unicode branch, they will break the trunk when the
 > Unicode branch is merged into it.  So I see no disadvantage here.

There would be no record of when things broke or a way of continuing with
Unicode only changes, if desired.  Anyway, while I think finding compromise
would be nice, I don't think Richard believes in it.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Syncing Gnus and Emacs repositories

[Richard Stallman]

    > However, it might be a problem if the changes on the branch break
    > things.

    If they break the Unicode branch, they will break the trunk when the
    Unicode branch is merged into it.  So I see no disadvantage here.

I agree.  Also, if a package is installed in unicode-2 and has a bad
interaction with part of unicode-2, people will have a chance to fix
the bug within unicode-2 before the merge.

If several such things get installed into unicode over a period of a
month or two, fixing their bugs will also be spread over a month or
two.  That won't be stressful.

However, if these same packages are installed in the trunk instead,
then merging unicode-2 will provoke all the bugs at once, which would
be rather unpleasant.


By contrast, if we 

Re: Syncing Gnus and Emacs repositories

[Eli Zaretskii]

> Cc: Kenichi Handa <handa@m17n.org>,  emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Mon, 18 Jun 2007 07:18:15 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Kenichi Handa <handa@m17n.org>
> >> CC: dak@gnu.org, emacs-devel@gnu.org
> >> Date: Mon, 18 Jun 2007 08:07:28 +0900
> >> 
> >> No.  I asked to merge unicode-2 into the trunk, but as it
> >> was not accepted, I asked not to make heavy changes to the
> >> trunk unless one takes care of emacs-unicode-2 branch too.
> >
> > So in that case, making such changes in the Unicode branch directly,
> > as I suggested, would be a good way of installing changes without
> > interfering with the future merge, right?
> 
> Could you explain how putting _unrelated_ changes into the Unicode
> branch would not interfere with a merge?

In the above, by ``without interfering'' I meant that it will not make
Kenichi's work harder when the Unicode branch is merged.

I don't see any way of zero interference, as long as there's a branch
(actually, two of them) waiting to be merged RSN.  But I think
installing ``heavy changes'' in the Unicode branch will tend to
minimize the interference.

Re: Syncing Gnus and Emacs repositories

[Richard Stallman]

    Could you explain how putting _unrelated_ changes into the Unicode
    branch would not interfere with a merge?

The normal case is that changes do not interfere.  Interference
happens only for specific causes.

Re: Syncing Gnus and Emacs repositories

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > From: Kenichi Handa <handa@m17n.org>
 > > CC: dak@gnu.org, emacs-devel@gnu.org
 > > Date: Mon, 18 Jun 2007 08:07:28 +0900
 > > 
 > > No.  I asked to merge unicode-2 into the trunk, but as it
 > > was not accepted, I asked not to make heavy changes to the
 > > trunk unless one takes care of emacs-unicode-2 branch too.
 > 
 > So in that case, making such changes in the Unicode branch directly,
 > as I suggested, would be a good way of installing changes without
 > interfering with the future merge, right?

Assuming that those making changes in the Unicode branch are
thoroughly familiar with it, yes.  If (as seems more likely), most
developers will split their attention three ways, between 22.x
bugfixes, permissible changes to the trunk, and blue-sky changes to
the emacs-unicode-2 branch, then people will care most about their own
blue-sky changes, and know very little about regressions in
emacs-unicode-2, until pointed out to them.  But emacs-unicode-2 will
be a branch, still, and will not get so much testing.  The risk of
regression in emacs-unicode-2 work seems substantial.  If I were
Handa-san, I would resist opening that branch to commits related to
work that could be done in non-emacs-unicode-2 branches.

Also, David Kastrup is quite right about the deficiencies of CVS.
XEmacs did something similar to what is being proposed here.  Under
pressure from people who were not primarily interested in the 21.4
release, we branched in January 2001, pushing blue-sky projects off on
a branch, and keeping 21.4 on the trunk.  It immediately became clear
this was unsustainable due to the difficulty of using cvs annotate,
cvs diff, and cvs update -j with mainline on a CVS branch.  So in
April 2001, less than three months later, we transplanted the trunk
(starting from the fork) to a new release-21-4 branch, and the 21.5
branch back to the trunk, at fairly high cost in current usefulness of
annotate, diff and update -j.  However, with mainline on the branch,
that cost was increasing rapidly, while with mainline on the trunk,
the cost decreased to negligible by the end of summer 2001.  While in
the end we avoided total disaster, the rationalization effort was
unaccompanied by any net benefit whatsoever, in fact, there were net
costs both before and after the rationalization compared to doing it
right by putting mainline on the trunk as soon was the 21.4 feature
freeze was implemented.

Caveat: as of CVS 1.12 or so, the -r TAG:DATE option format is
available.  This might mitigate the very strong bias of CVS in favor
of comparisons with and merges to trunk.  However, because of the
structure of ,v files, there is no question that after a few hundred
commits work that involves both mainline and another branch will
become painfully inefficient.

N.B. Emacs's situation is somewhat different from XEmacs 21.4, as
people seem willing to accept an across-the-board freeze during the
release cycle.  However, given that the EMACS_22_BASE branch now
exists, IMO *all* large merges and other potentially destabilizing
changes should be done to the trunk where they will get maximum
testing; the only question is whether they should be synchronized to
events in Emacs 22 for some reason, or whether the trunk should be
opened now to merge of emacs-unicode-2 and so on, subject to
negotiation among the developers working on the trunk (ie, not
considering effects on Emacs 22).

Bottom line: The risks are high, the benefits are small.  I strongly
recommend against doing substantial work on a CVS branch, unless it
has a single theme and is explicitly aimed at a single merge to
mainline, then retirement.

If Richard sustains his veto of merging emacs-unicode-2 and other
potentially destabilizing work on the trunk, then, based on that
experience, I see only two practical choices.  (1) Accept that the
trunk will stay in feature slush for a while, and work on the
branch(es) that interest you in separate workspaces until permission
is given to merge to trunk.  (2) Switch to a distributed SCM like Arch
or git for cooperative work on merged workspaces, and use CVS only to
maintain continuity of communication with the rest of the world and
those whose current work is focused on the 22.x branch or features
admissible on the trunk in CVS.  (Subversion is not a panacea here.)

Re: Syncing Gnus and Emacs repositories

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

[Relevant experience, thanks for that.]

> If Richard sustains his veto of merging emacs-unicode-2 and other
> potentially destabilizing work on the trunk, then, based on that
> experience, I see only two practical choices.  (1) Accept that the
> trunk will stay in feature slush for a while, and work on the
> branch(es) that interest you in separate workspaces until permission
> is given to merge to trunk.  (2) Switch to a distributed SCM like
> Arch or git for cooperative work on merged workspaces, and use CVS
> only to maintain continuity of communication with the rest of the
> world and those whose current work is focused on the 22.x branch or
> features admissible on the trunk in CVS.  (Subversion is not a
> panacea here.)

Subversion would not really help since it is basically "CVS done
right" (TM) and thus the problems are similar.  Distributed SCMs are
actually not a matter of developer policy: the adoption of them
basically remains the individuals' choice.  I am currently fighting
with git-archimport in order to get a useful starting point for
working with multi-tty and its history, but might have to do a direct
CVS import into git instead.

-- 
David Kastrup

Re: Syncing Gnus and Emacs repositories

[Stephen J. Turnbull]

David Kastrup writes:

 > right" (TM) and thus the problems are similar.  Distributed SCMs are
 > actually not a matter of developer policy: the adoption of them
 > basically remains the individuals' choice.

If they are used as a means of cooperation, it becomes a policy issue.

[[ aside, as long as I'm here

 > I am currently fighting with git-archimport in order to get a
 > useful starting point for working with multi-tty and its history,
 > but might have to do a direct CVS import into git instead.

Have you tried Tailor?

http://wiki.darcs.net/index.html/Tailor

(nb Tailor is mostly independent of darcs, but in my experience
darcs.net is higher availability than Lele's page.)
]]

Re: Syncing Gnus and Emacs repositories

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> David Kastrup writes:
>
>  > right" (TM) and thus the problems are similar.  Distributed SCMs are
>  > actually not a matter of developer policy: the adoption of them
>  > basically remains the individuals' choice.
>
> If they are used as a means of cooperation, it becomes a policy
> issue.

Yes and no.  If they are used as a means of cooperation among a group
working around the limitations of the main project's policies, having
a "policy" would imply something like an "administrational fork", an
impression which people want to avoid like the plague.

git's history basically is a management tool for patch sets.
Developers may or may not use it without affecting the overall
project.  I have quite a few project with a central Subversion
repository where I manage my local work and branches using git.

> [[ aside, as long as I'm here
>
>  > I am currently fighting with git-archimport in order to get a
>  > useful starting point for working with multi-tty and its history,
>  > but might have to do a direct CVS import into git instead.
>
> Have you tried Tailor?
>
> http://wiki.darcs.net/index.html/Tailor
>
> (nb Tailor is mostly independent of darcs, but in my experience
> darcs.net is higher availability than Lele's page.)
> ]]

Not yet.  Thanks for the pointer.

-- 
David Kastrup

Re: Syncing Gnus and Emacs repositories

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Kenichi Handa <handa@m17n.org>,
>     emacs-devel@gnu.org
> Date: Mon, 18 Jun 2007 15:53:09 +0900
> 
>  > So in that case, making such changes in the Unicode branch directly,
>  > as I suggested, would be a good way of installing changes without
>  > interfering with the future merge, right?
> 
> Assuming that those making changes in the Unicode branch are
> thoroughly familiar with it, yes.

Are you sure such a thorough familiarity is indeed required?  AFAIK,
most of the radical changes in the Unicode branch are fairly
low-level; the changes to application-level APIs are relatively minor
and matter in marginal cases.  E.g., most Lisp programs should not
care about the internal representation of characters in buffers and
strings.  Emacs 22 already unifies Latin and various other scripts in
a way that, at least on the outside, closely resembles Unicode-based
representation of characters.

Handa-san, can you comment on this?

> Bottom line: The risks are high, the benefits are small.  I strongly
> recommend against doing substantial work on a CVS branch

Well, the Unicode branch exists for a long time, so we are already
there.

> unless it has a single theme and is explicitly aimed at a single
> merge to mainline, then retirement.

I don't see how the CVS deficiencies are not relevant for a
single-theme development.

In any case, I think switching to Unicode can hardly be classified as
``single-theme'', since it touches so many internals.

Re: Syncing Gnus and Emacs repositories

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Are you sure such a thorough familiarity is indeed required?

I am not a prophet.  I offered my experience.  You are free to learn
something from it, or not.  I am not a witness under oath.  To the
extent that your questions can be answered from my experience, they
all were answered already; I decline to submit to hostile cross-
examination.

Re: Syncing Gnus and Emacs repositories

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>
> Cc: emacs-devel@gnu.org,
>     handa@m17n.org
> Date: Tue, 19 Jun 2007 09:53:38 +0900
> 
> Eli Zaretskii writes:
> 
>  > Are you sure such a thorough familiarity is indeed required?
> 
> I decline to submit to hostile cross- examination.

I'm bewildered how you read hostility into a simple question, but
whatever.

Re: Syncing Gnus and Emacs repositories

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>
>> Cc: emacs-devel@gnu.org,
>>     handa@m17n.org
>> Date: Tue, 19 Jun 2007 09:53:38 +0900
>> 
>> Eli Zaretskii writes:
>> 
>>  > Are you sure such a thorough familiarity is indeed required?
>> 
>> I decline to submit to hostile cross- examination.
>
> I'm bewildered how you read hostility into a simple question, but
> whatever.

It may not be hostility, but there seems little point in picking apart
a report of experience and putting the burden of drawing conclusions
from it on the reporter lest it go unheeded (which it may after all).
While this has developed into something like an art form on this list,
it is nothing I am particularly proud of.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Syncing Gnus and Emacs repositories

[Eli Zaretskii]

> Cc: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>,  handa@m17n.org,
> 	  emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Tue, 19 Jun 2007 07:37:16 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>
> >> Cc: emacs-devel@gnu.org,
> >>     handa@m17n.org
> >> Date: Tue, 19 Jun 2007 09:53:38 +0900
> >> 
> >> Eli Zaretskii writes:
> >> 
> >>  > Are you sure such a thorough familiarity is indeed required?
> >> 
> >> I decline to submit to hostile cross- examination.
> >
> > I'm bewildered how you read hostility into a simple question, but
> > whatever.
> 
> It may not be hostility, but there seems little point in picking apart
> a report of experience and putting the burden of drawing conclusions
> from it on the reporter lest it go unheeded (which it may after all).

Jeez, guys, I just asked a honest question, because I really _wanted_
to understand whether Stephen knew something about the Unicode branch
that I didn't.

> While this has developed into something like an art form on this list,

Well, whatever art it developed into, I don't subscribe to it.  Most
of this thread I was rather silent anyway.

Re: Syncing Gnus and Emacs repositories

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Jeez, guys, I just asked a honest question, because I really _wanted_
 > to understand whether Stephen knew something about the Unicode branch
 > that I didn't.

I don't claim to know anything special about the Unicode branch,
because in fact I don't.  What I do know about from experience is what
happens when you try to conduct mainline development on a CVS branch,
and I have enough knowledge of what is involved in Mule work and in
converting from Mule code to Unicode to be confident that
emacs-unicode-2 is not exempt from the generic problems.

Your questions may have been "simple" and "honest" to you, but they
looked like attempts to score debating points to me.  Here are my
"simple" and "honest" answers:

 >>> So in that case, making such changes in the Unicode branch directly,
 >>> as I suggested, would be a good way of installing changes without
 >>> interfering with the future merge, right?

 >> Assuming that those making changes in the Unicode branch are
 >> thoroughly familiar with it, yes.

 > Are you sure such a thorough familiarity is indeed required?  AFAIK,
 > most of the radical changes in the Unicode branch are fairly
 > low-level;

Statistically, I'm sure.  If extra work is conducted on the branch,
there is some probability of collision.  Since by definition that work
is too disruptive for the trunk, I suppose it's higher than you might
otherwise think.  The more work you force into that branch, the more
disruption.  It's possible that no mistakes will be made.  Why risk
that they will?

 >> Bottom line: The risks are high, the benefits are small.

Nobody has proposed any significant benefits to this, except that it's
a "compromise".  Why take *any* risk, just for the sake of a nominal
compromise?

OTOH, all of your arguments *do* apply to opening the trunk to merge
of emacs-unicode-2 (and other disruptive features).  I see very little
risk in opening the trunk *now*, not even in terms of packages that
would be ported to Emacs 22.2-on-the-trunk but not Emacs
22.2-on-a-branch.

 >> I strongly recommend against doing substantial work on a CVS
 >> branch

 > Well, the Unicode branch exists for a long time, so we are already
 > there.

[That is not an attempt at dialog!]

 >> unless it has a single theme and is explicitly aimed at a single
 >> merge to mainline, then retirement.

 > I don't see how the CVS deficiencies are not relevant for a
 > single-theme development.

Because in single-theme development the flow is one-way, from trunk to
branch, until you decide to merge.  You don't even want to port typo
fixes in docstrings back, because they *will* cause merge conflicts.
This discipline is easy to maintain in single-theme development.

It is much harder to do with multiple developers who think of the
branch as "home" to their projects, but not of themselves as members
of all the projects.  It sounds counter-intuitive, but it is a fact
that such merge conflicts creep in.  Surprisingly often they strike in
places where it's hard to determine which hunk is the "true" one.[1]
I recall on several occasions looking at a pair of hunks, one of which
I wrote, but not knowing which one!  In CVS it's not easy to find out,
you need to talk to the server.

Second, effectively a line of development where independent projects
are being conducted is in a continuous state of merge.  Conflicts
arise, collisions in simultaneous commits are very hard to straighten
out since CVS commits to multiple files are not atomic, and the
repository ends up being inconsistent with *all* developers'
workspaces.  Your best hope of keeping this straight is to use CVS
itself to keep individual projects on subbranches, but then you *do*
run into the CVS deficiencies with branch-to-branch work.

 > In any case, I think switching to Unicode can hardly be classified
 > as ``single-theme'', since it touches so many internals.

[Another dialog-killer.  Obviously, I had a reason for classifying it
so.  Why do you deny it without asking WTF I'm talking about?]

Let me quote from a master:

    I will contend that conceptual integrity is *the* most important
    consideration in system design.  It is better to have a system
    omit certain anomolous features and improvements, but to reflect
    one set of design ideas, than to have one that contains many good
    but independent and uncoordinated ideas.  ... It is not enough to
    learn the elements and rules of combination; one must also learn
    the idiomatic usage, a whole lore of how the elements are combined
    in practice.  ... Every part must even use the same techniques in
    syntax and analogous notions in semantics.  Ease of use, then,
    dictates unity of design, conceptual integrity.  Conceptual
    integrity in turn dictates that the design must proceed from one
    mind.... [Frederick Brooks, _The Mythical Man-Month_, Ch. 4]

The emacs-unicode-2 branch is mostly the work of one man, Ken'ichi
Handa.  Having observed Handa-san's work in the past, I'm willing to
bet it has conceptual integrity.  In other words, it has a theme:
changing the internal coding from Mule coding to Unicode while
maintaining the look and feel of Emacs and conforming to Unicode.  All
of the myriad of little changes can be described by that theme.

As you point out from a different point of view, as soon as it gets
merged to trunk, that conceptual integrity will start to break down.
But at that point, the theme is *part of Emacs*, and the developer
community will quickly come to learn to try to conserve it.  As long
as it's on a branch, it has no such status, it must fend for itself.
If in that branch it must compete with other independent projects for
attention, the conceptual integrity will start to degrade.  This isn't
part of my XEmacs 21.4 release experience, but I've observed both the
instinct to conserve "XEmacsness" and degradation of conceptual
integrity on many occasions in XEmacs.

For a question as central to a text editor as "what is a character?",
I think conceptual integrity is something to be preserved at almost
any cost.

Once again, I don't contend this all is always true, but in this case
I see significant risk to the strategy of opening emacs-unicode-2 to
commits other than those approved specifically by Handa-san, and no
gain.


Footnotes: 
[1]  Bram Cohen of BitTorrent fame claims that his "patience diff"
algorithm helps this a lot, but none of the projects I work on use bzr
yet, so I don't know.

Re: Syncing Gnus and Emacs repositories

[David Kastrup]

"Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp> writes:

> Eli Zaretskii writes:
>
>  > Are you sure such a thorough familiarity is indeed required?
>
> I am not a prophet.

Well, this is the Church of Emacs we are talking about...

> I offered my experience.  You are free to learn something from it,
> or not.

And I was pleasantly surprised for this advice which was earnt the
hard way and offered freely to a project which can't exactly be
expected to be close to your heart.

However, our track record of experience against (let's call it)
optimism is not exactly impressive.  This may not be all bad at all
times: after all, Emacs has been declared doomed quite a number at
times, and has kept up.

I, for one, am grateful for the contributions you still make in spite
of their reception.  While you are not singled out in this kind of
reception, you'd have more reason than others to stop bothering, and I
appreciate that you still do your part in trying to prevent the
unnecessary reiteration of mistakes.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Syncing Gnus and Emacs repositories

[Kenichi Handa]

In article <u8xahrrsb.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> >  > So in that case, making such changes in the Unicode branch directly,
> >  > as I suggested, would be a good way of installing changes without
> >  > interfering with the future merge, right?
> > 
> > Assuming that those making changes in the Unicode branch are
> > thoroughly familiar with it, yes.

> Are you sure such a thorough familiarity is indeed required?  AFAIK,
> most of the radical changes in the Unicode branch are fairly
> low-level; the changes to application-level APIs are relatively minor
> and matter in marginal cases.  E.g., most Lisp programs should not
> care about the internal representation of characters in buffers and
> strings.  Emacs 22 already unifies Latin and various other scripts in
> a way that, at least on the outside, closely resembles Unicode-based
> representation of characters.

> Handa-san, can you comment on this?

What you wrote in the above paragraph is almost right.

But, fairly big programs (especially gnus, and the other
mail tools) have to pay attention to characters decoding and
encoding, and almost all workarounds for the Emacs 22's
legacy charset/code-point model get wrong (or unnecessary)
for emacs-unicode.  Some of already existing workarounds may
have bugs (or shortages).  More the merging delays, the
possibility of people spending their time for fixing them in
vain gets higher.  In addition, such a fix in the trunk
tends to cause confliction when merged into emacs-unicode-2
branch.

---
Kenichi Handa
handa@m17n.org

Re: Syncing Gnus and Emacs repositories

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> CC: stephen@xemacs.org, emacs-devel@gnu.org
> Date: Tue, 19 Jun 2007 11:19:59 +0900
> 
> But, fairly big programs (especially gnus, and the other
> mail tools) have to pay attention to characters decoding and
> encoding, and almost all workarounds for the Emacs 22's
> legacy charset/code-point model get wrong (or unnecessary)
> for emacs-unicode.

Yeah, I forgot about Gnus and the legacy of workarounds that comes
with it.

> More the merging delays, the possibility of people spending their
> time for fixing them in vain gets higher.

Well, FWIW, I agree that the delay should be as short as possible.

Re: Syncing Gnus and Emacs repositories

[Giorgos Keramidas]

On 2007-06-18 15:53, "Stephen J. Turnbull" <stephen@xemacs.org> wrote:
> Also, David Kastrup is quite right about the deficiencies of CVS.
> XEmacs did something similar to what is being proposed here.  Under
> pressure from people who were not primarily interested in the 21.4
> release, we branched in January 2001, pushing blue-sky projects off on
> a branch, and keeping 21.4 on the trunk.  It immediately became clear
> this was unsustainable due to the difficulty of using cvs annotate,
> cvs diff, and cvs update -j with mainline on a CVS branch.  So in
> April 2001, less than three months later, we transplanted the trunk
> (starting from the fork) to a new release-21-4 branch, and the 21.5
> branch back to the trunk, at fairly high cost in current usefulness of
> annotate, diff and update -j.  However, with mainline on the branch,
> that cost was increasing rapidly, while with mainline on the trunk,
> the cost decreased to negligible by the end of summer 2001.  While in
> the end we avoided total disaster, the rationalization effort was
> unaccompanied by any net benefit whatsoever, in fact, there were net
> costs both before and after the rationalization compared to doing it
> right by putting mainline on the trunk as soon was the 21.4 feature
> freeze was implemented.

That's very interesting.  I am not watching the development of XEmacs
very closely, but can you please describe how developing on a 'release
branch' made things difficult for XEmacs?  Please feel free to email me
privately if this would increase the noise in emacs-devel, without a lot
of benefit for Emacs developers.

I'm asking because of my existing experience with how the FreeBSD CVS
tree is used to work on FreeBSD development.

It may not be very useful for Emacs development, but the model used by
the FreeBSD CVS tree is:

       [1]
    ----X--------------------------> trunk
        |        :        :
        |        :        :
        +-----------X--------X--> RELENG_6
                   [2]      [3]
                    |        |
                    |        |
                    |        +--- RELENG_6_1
                    |
                    |
                    +------------ RELENG_6_0

Where 'X' points are tags, and ':' lines denote selective merging of
features from the CVS trunk.

  1 == RELENG_6_BP
  2 == RELENG_6_0_0_RELEASE
  3 == RELENG_6_1_0_RELEASE

When the CVS trunk is considered ready for the 6.X branch, we freeze
trunk, the release engineering team tags the trunk as RELENG_6_BP and
the RELENG_6 branch is branched off RELENG_6_BP.

Some time after the release branch RELENG_6 stabilizes enough for us to
roll out a release, we freeze the RELENG_6 and finally we tag it with
RELENG_6_0_0_RELEASE and then we create a 'security branch' off the
release tag (RELENG_6_0).

Each release is tagged with RELENG_X_Y_Z_RELEASE.

Each release has an associated RELENG_X_Y security branch, which can
accept _only_ security fixes and nothing else.

Each major line of development has its own RELENG_X 'mainline'.

Development of cutting edge features, which may be unstable for long
periods of time, experimental, or even be completely removed before they
ever hit a release branch is done in the CVS trunk.

Development of 'stable' versions, which can only make conservative
bugfix and security fix changes, is done in the RELENG_X mainline.

I don't know if such a model would fit the development of Emacs, or if
the description was clear enough.  Please feel free to ask any questions
regarding the way we branch or tag FreeBSD, or how the release process
of FreeBSD is organized around CVS.  It if helps us make the development
of Emacs more 'streamlined', then I'll be glad to work with the main
Emacs developers to see which parts of the FreeBSD model can fit the way
the development of Emacs works already and which parts we can adopt to
improve things :)

- Giorgos

Re: Syncing Gnus and Emacs repositories

[Richard Stallman]

    The current plan, however, seems to be "let's achieve as little as
    possible over as long as possible".

Even if you disagree with my decision, there is no excuse
for trying to read ill will into it.  If you cannot speak
in a way that isn't insulting, then stay out of the discussion.

Proposal for a 22.2/trunk development model (was: Syncing Gnus and Emacs repositories)

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  > I have decided that we should not merge unicode-2 until a couple of
  > months have gone by and we know what should be done about Emacs 22.2.
  > Until then I want to avoid far-reaching changes in the trunk.
  > Please stop making a fuss about a couple of months.
  > 
  > However, it is ok to add new features which are not so far-reaching in
  > their effects on the code.  Even the multi-tty branch could be merged
  > in (once we decide what to do about the environment).

This development model would undoubtedly achieve the goal of being
able to make a high quality 22.2 release. 

Here is a proposal that would still achieve the same goal, with the
added advantage that it would get us closer to a future 23.1 release
at a higher speed:
 * ask for 2-3 (or more) volunteers that would: 
     - backport all the changes that you'd consider important from
     trunk to the 22.x branch
     - develop fixes for bugs that only occur on the 22.x branch
     - analyze the reported 22.1 bugs and fix them or ask for help to
     fix them
     - ask you to stop all development on the trunk until some critical
     bug is fixed on the branch. 
 * open the trunk for any new development 
   Now, during the summer, is a very good time to allow for more
   development to happen: a lot of people have more free time, we'd
   want them to use that time for emacs as much as possible.
      
Do you find such a plan acceptable? IMHO a plan like this would
satisfy the people that ask for more development on the trunk. 

Please let us know. 

Thanks!

        --dan

PS: In order to reduce the number of messages on the list, please
 allow RMS to reply to this and agree/disagree with the principle of
 this before posting alternate better plans or improvements to this
 one.

Re: Proposal for a 22.2/trunk development model

[David Kastrup]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>   > I have decided that we should not merge unicode-2 until a couple
>   > of months have gone by and we know what should be done about
>   > Emacs 22.2.  Until then I want to avoid far-reaching changes in
>   > the trunk.  Please stop making a fuss about a couple of months.
>   > 
>   > However, it is ok to add new features which are not so
>   > far-reaching in their effects on the code.  Even the multi-tty
>   > branch could be merged in (once we decide what to do about the
>   > environment).
>
> This development model would undoubtedly achieve the goal of being
> able to make a high quality 22.2 release.

Undoubtedly?  Richard is talking about the trunk, you are talking
about 22.2 which is to be done off EMACS_22_BASE.  So I don't see the
two areas actually related, _unless_ one plans to _scrap_
EMACS_22_BASE and basically copy trunk over it.  Which nobody has
proposed, and which I'd consider an even worse idea than quite a few
others I have blown my top over.

> Here is a proposal that would still achieve the same goal, with the
> added advantage that it would get us closer to a future 23.1 release
> at a higher speed:
>  * ask for 2-3 (or more) volunteers that would: 
>      - backport all the changes that you'd consider important from
>      trunk to the 22.x branch
>      - develop fixes for bugs that only occur on the 22.x branch
>      - analyze the reported 22.1 bugs and fix them or ask for help to
>      fix them

I think that analyzing and fixing reported bugs should remain the
responsibility of every developer: we don't want to have something as
important as that go through the 22.x bottleneck.

>      - ask you to stop all development on the trunk until some critical
>      bug is fixed on the branch.

Huh?  Care for an example, hypothetical if you like?

>  * open the trunk for any new development
>    Now, during the summer, is a very good time to allow for more
>    development to happen: a lot of people have more free time, we'd
>    want them to use that time for emacs as much as possible.

The trunk _has_ been formally opened for new development.  It is just
several people have dissenting ideas about what this does and what it
should mean.

> Do you find such a plan acceptable? IMHO a plan like this would
> satisfy the people that ask for more development on the trunk.

In the end, it does not matter what words we put into a plan.  It only
counts what we will be doing.

> PS: In order to reduce the number of messages on the list, please
> allow RMS to reply to this and agree/disagree with the principle of
> this before posting alternate better plans or improvements to this
> one.

Richard already _did_ declare the trunk open for new development.
Getting him to agree again seems pretty pointless: in the abstract, we
already _have_ consensus.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Proposal for a 22.2/trunk development model

[Dan Nicolaescu]

David Kastrup <dak@gnu.org> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > Richard Stallman <rms@gnu.org> writes:
  > >
  > >   > I have decided that we should not merge unicode-2 until a couple
  > >   > of months have gone by and we know what should be done about
  > >   > Emacs 22.2.  Until then I want to avoid far-reaching changes in
  > >   > the trunk.  Please stop making a fuss about a couple of months.
  > >   > 
  > >   > However, it is ok to add new features which are not so
  > >   > far-reaching in their effects on the code.  Even the multi-tty
  > >   > branch could be merged in (once we decide what to do about the
  > >   > environment).
  > >
  > > This development model would undoubtedly achieve the goal of being
  > > able to make a high quality 22.2 release.
  > 
  > Undoubtedly?  Richard is talking about the trunk, you are talking
  > about 22.2 which is to be done off EMACS_22_BASE.  So I don't see the
  > two areas actually related, _unless_ one plans to _scrap_
  > EMACS_22_BASE and basically copy trunk over it.  Which nobody has
  > proposed, and which I'd consider an even worse idea than quite a few
  > others I have blown my top over.


Your attitude is completely puzzling to me. I made a concrete,
constructive proposal to RMS to try to move things in the direction
that you seem to want too. Instead of waiting for his reply (as I
politely asked) and try to have a constructive discussion after that,
you chose to be destructive and nitpick my proposal.

Sorry, but I think that a discussion along the lines you started is
not going to get anywhere, so I'll stop here.

Deeply disappointed,
      
         --dan

Re: Proposal for a 22.2/trunk development model

[David Kastrup]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> David Kastrup <dak@gnu.org> writes:
>
>   > Dan Nicolaescu <dann@ics.uci.edu> writes:
>   > 
>   > > Richard Stallman <rms@gnu.org> writes:
>   > >
>   > >   > I have decided that we should not merge unicode-2 until a
>   > >   > couple of months have gone by and we know what should be
>   > >   > done about Emacs 22.2.  Until then I want to avoid
>   > >   > far-reaching changes in the trunk.  Please stop making a
>   > >   > fuss about a couple of months.
>   > >   > 
>   > >   > However, it is ok to add new features which are not so
>   > >   > far-reaching in their effects on the code.  Even the
>   > >   > multi-tty branch could be merged in (once we decide what
>   > >   > to do about the environment).
>   > >
>   > > This development model would undoubtedly achieve the goal of being
>   > > able to make a high quality 22.2 release.
>   > 
>   > Undoubtedly?  Richard is talking about the trunk, you are
>   > talking about 22.2 which is to be done off EMACS_22_BASE.  So I
>   > don't see the two areas actually related, _unless_ one plans to
>   > _scrap_ EMACS_22_BASE and basically copy trunk over it.  Which
>   > nobody has proposed, and which I'd consider an even worse idea
>   > than quite a few others I have blown my top over.
>
> Your attitude is completely puzzling to me. I made a concrete,
> constructive proposal to RMS to try to move things in the direction
> that you seem to want too. Instead of waiting for his reply (as I
> politely asked)

Since Richard _has_ already declared the trunk open for new
development, there is no point in asking him to declare the trunk open
for new development _again_.  There is also no point in waiting for
him to do so _unless_ you are of the opinion that he changed his mind
about that.

> and try to have a constructive discussion after that, you chose to
> be destructive and nitpick my proposal.

There is simply no point in proposing things (or rather wordings) that
have already been agreed upon.  The differences here are about what it
_means_ to have the trunk open for new development.  It _is_ already
declared so by Richard.

> Sorry, but I think that a discussion along the lines you started is
> not going to get anywhere, so I'll stop here.

I also see that the discussion along the lines I started (namely that
among the three unicode-2, trunk, EMACS_22_BASE there clearly is one
too many for sensible development focused on a 22.2 and a 23.1
release) is not going anywhere.  But discussing some other problem
which we have tackled already does not seem like a useful alternative.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Proposal for a 22.2/trunk development model

[Dan Nicolaescu]

David Kastrup <dak@gnu.org> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > David Kastrup <dak@gnu.org> writes:
  > >
  > >   > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > >   > 
  > >   > > Richard Stallman <rms@gnu.org> writes:
  > >   > >
  > >   > >   > I have decided that we should not merge unicode-2 until a
  > >   > >   > couple of months have gone by and we know what should be
  > >   > >   > done about Emacs 22.2.  Until then I want to avoid
  > >   > >   > far-reaching changes in the trunk.  Please stop making a
  > >   > >   > fuss about a couple of months.
  > >   > >   > 
  > >   > >   > However, it is ok to add new features which are not so
  > >   > >   > far-reaching in their effects on the code.  Even the
  > >   > >   > multi-tty branch could be merged in (once we decide what
  > >   > >   > to do about the environment).
  > >   > >
  > >   > > This development model would undoubtedly achieve the goal of being
  > >   > > able to make a high quality 22.2 release.
  > >   > 
  > >   > Undoubtedly?  Richard is talking about the trunk, you are
  > >   > talking about 22.2 which is to be done off EMACS_22_BASE.  So I
  > >   > don't see the two areas actually related, _unless_ one plans to
  > >   > _scrap_ EMACS_22_BASE and basically copy trunk over it.  Which
  > >   > nobody has proposed, and which I'd consider an even worse idea
  > >   > than quite a few others I have blown my top over.
  > >
  > > Your attitude is completely puzzling to me. I made a concrete,
  > > constructive proposal to RMS to try to move things in the direction
  > > that you seem to want too. Instead of waiting for his reply (as I
  > > politely asked)
  > 
  > Since Richard _has_ already declared the trunk open for new
  > development, there is no point in asking him to declare the trunk open
  > for new development _again_.  

No, it is not open for "_any_ new development", that would mean
unicode-2 could get in. 

Re: Proposal for a 22.2/trunk development model (was: Syncing Gnus and Emacs repositories)

[Richard Stallman]

Please forgive me for taking so long to respond to your message.

    Here is a proposal that would still achieve the same goal, with the
    added advantage that it would get us closer to a future 23.1 release
    at a higher speed:
     * open the trunk for any new development 
       Now, during the summer, is a very good time to allow for more
       development to happen: a lot of people have more free time, we'd
       want them to use that time for emacs as much as possible.

The trunk is open now for nearly all new development.
For instance, I hope we will merge the multi-tty branch in a few days.

The only exception is unicode-2, but that exception won't last long.
I hope we will make a 22.2 release in a few weeks; after that, we
could merge unicode-2 also.

Now, turning to your suggestion:

     * ask for 2-3 (or more) volunteers that would: 
	 - backport all the changes that you'd consider important from
	 trunk to the 22.x branch
	 - develop fixes for bugs that only occur on the 22.x branch
	 - analyze the reported 22.1 bugs and fix them or ask for help to
	 fix them
	 - ask you to stop all development on the trunk until some critical
	 bug is fixed on the branch. 

You proposed this as a way to get the trunk open for new development
by everyone else.  It isn't needed for that purpose, but it would
be useful for the sake of making the Emacs 22.2 release without delays.

Actually it is just a matter of fixing the bugs that are reported.

Would people like to volunteer for this?

Re: Syncing Gnus and Emacs repositories

[Richard Stallman]

    > I said weeks ago people can install new features in the trunk now.
    > What uncertainty remains?

    Did you mean, everything except the unicode code?

More or less.  Merging multi-tty is ok once we decide what to do
with the environment, and do it.

Re: Syncing Gnus and Emacs repositories

[Jay Belanger]

Richard Stallman <rms@gnu.org> writes:
...
> I said weeks ago people can install new features in the trunk now.
> What uncertainty remains?

I must have missed that message.  Thanks for the reminder.

Jay

Re: Syncing Gnus and Emacs repositories

[Reiner Steib]

On Wed, Jun 13 2007, Reiner Steib wrote:

> On Wed, Jun 13 2007, Stefan Monnier wrote:
>
>>> IMHO, now it would more sense to merge these changes to EMACS_22_BASE
>>> (the 22.x release branch in Emacs' repository) instead.  Changes in
>>> v5-10 are only bug- and doc-fixes, so we should have all these changes
>>> in Emacs 22.2 as well.
>>
>>> Miles, could you arrange this (unless there are objections)?

Thanks for setting this up, Miles.

>> Agreed.   And I'd also argue that the Emacs trunk version of Gnus should be
>> upgraded to the Gnus trunk now (and then kept in sync).
>
> Funny, that's what I suggested to Lars this morning.  ;-) But I wanted
> to wait for his response before suggesting it here.

Lars has agreed and nobody has objected.

Miles, could you please set up syncing Gnus trunk and Emacs trunk as
well (after your vacation)?

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

Re: Syncing Gnus and Emacs repositories

[Miles Bader]

Reiner Steib <reinersteib+gmane@imap.cc> writes:
>>> Agreed.   And I'd also argue that the Emacs trunk version of Gnus should be
>>> upgraded to the Gnus trunk now (and then kept in sync).
>>
>> Funny, that's what I suggested to Lars this morning.  ;-) But I wanted
>> to wait for his response before suggesting it here.
>
> Lars has agreed and nobody has objected.
>
> Miles, could you please set up syncing Gnus trunk and Emacs trunk as
> well (after your vacation)?

I'm back from my holiday, and I'd like to just confirm once more that
it's OK to change the version of Gnus in the Emacs trunk to be the
current Gnus trunk.  [Didn't see any comments in response to this
thread.]

Thanks,

-Miles

-- 
/\ /\
(^.^)
(")")
*This is the cute kitty virus, please copy this into your sig so it can spread.

Re: Syncing Gnus and Emacs repositories

[Richard Stallman]

    I'm back from my holiday, and I'd like to just confirm once more that
    it's OK to change the version of Gnus in the Emacs trunk to be the
    current Gnus trunk.

On general principles, it is fine.
Whether there is some specific reason not to,
I would not know.

Re: Syncing Gnus and Emacs repositories

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     I'm back from my holiday, and I'd like to just confirm once more that
>     it's OK to change the version of Gnus in the Emacs trunk to be the
>     current Gnus trunk.
>
> On general principles, it is fine.
> Whether there is some specific reason not to,
> I would not know.

I tried a test-merge and one problem I ran into is that the Gnus trunk
contains a "newer" version of pgg*.el, which has been abandoned by its
author and as I recall was rejected for merging into Emacs.

I'd suggest that the proper thing to do (supported by a previous
discussion on the Gnus developer list) is first revert the version of
pgg in the Gnus trunk to that in the Gnus 5.10 branch, and perhaps wait
a while for any bugs to be fixed before merging the Gnus trunk into
Emacs.

Is there anybody who can do that (revert pgg in the Gnus trunk to the
version in the 5.10 branch, and remove any unneeded files like
password.el)?  I can try to do it myself, but perhaps there are subtle
points of the interface between Gnus and pgg that I'd screw up...

Thanks,

-Miles

-- 
Americans are broad-minded people.  They'll accept the fact that a person can
be an alcoholic, a dope fiend, a wife beater, and even a newspaperman, but if a
man doesn't drive, there is something wrong with him.  -- Art Buchwald

Re: Syncing Gnus and Emacs repositories

[Daiki Ueno]

>>>>> In <buo3azwpmzb.fsf@dhapc248.dev.necel.com> 
>>>>>	Miles Bader <miles.bader@necel.com> wrote:
> I tried a test-merge and one problem I ran into is that the Gnus trunk
> contains a "newer" version of pgg*.el, which has been abandoned by its
> author and as I recall was rejected for merging into Emacs.

Indeed I (the author) did abandoned pgg*.el, and the Gnus trunk does not
use them by default.

> Is there anybody who can do that (revert pgg in the Gnus trunk to the
> version in the 5.10 branch, and remove any unneeded files like
> password.el)?  I can try to do it myself, but perhaps there are subtle
> points of the interface between Gnus and pgg that I'd screw up...

Could you describe the "subtle points"?  I'll try to fix that tomorrow.

Regards,
-- 
Daiki Ueno

Re: Syncing Gnus and Emacs repositories

[Leo]

On 10/07/2007, Daiki Ueno wrote:
>> I tried a test-merge and one problem I ran into is that the Gnus
>> trunk contains a "newer" version of pgg*.el, which has been abandoned
>> by its author and as I recall was rejected for merging into Emacs.
>
> Indeed I (the author) did abandoned pgg*.el, and the Gnus trunk does
> not use them by default.

If it is possible, let's just move to easypg, of which Daiki is also the
author.

-- 
Leo <sdl.web AT gmail.com>                         (GPG Key: 9283AA3F)

Re: Syncing Gnus and Emacs repositories

[Miles Bader]

Leo <sdl.web@gmail.com> writes:
>> Indeed I (the author) did abandoned pgg*.el, and the Gnus trunk does
>> not use them by default.
>
> If it is possible, let's just move to easypg, of which Daiki is also the
> author.

That can happen later.  For now let's just do the simple and
straight-forward thing.

-Miles

-- 
"1971 pickup truck; will trade for guns"

[bug] PGG shows ?? when prompt for passphrase

[Leo]

Hi all,

[Emacs 23 CVS:20061122, Gnus 5.11]

When decrypting an email, PGG shows in the minibuffer:

  GnuPG passphrase for ??:

Is this intentional or a bug?

-- 
Leo <sdl.web AT gmail.com>                         (GPG Key: 9283AA3F)

Re: [bug] PGG shows ?? when prompt for passphrase

[Daiki Ueno]

>>>>> In <m2bqm4tulm.fsf@sl392.st-edmunds.cam.ac.uk> 
>>>>>	Leo <sdl.web@gmail.com> wrote:
> When decrypting an email, PGG shows in the minibuffer:

>   GnuPG passphrase for ??:

> Is this intentional or a bug?

It looks intentional.

(format (if (pgg-gpg-symmetric-key-p message-keys)
	    "Passphrase for symmetric decryption: "
	  "GnuPG passphrase for %s: ")
	(or key-owner "??"))
-- 
Daiki Ueno

Re: [bug] PGG shows ?? when prompt for passphrase

[Leo]

Dear Daiki,

* Daiki Ueno (2006-12-17 10:30 +0900) said:
  ^^^^^^^^^^
>>>>>> In <m2bqm4tulm.fsf@sl392.st-edmunds.cam.ac.uk> 
>>>>>>	Leo <sdl.web@gmail.com> wrote:
>> When decrypting an email, PGG shows in the minibuffer:
>
>>   GnuPG passphrase for ??:
>
>> Is this intentional or a bug?
>
> It looks intentional.
>
> (format (if (pgg-gpg-symmetric-key-p message-keys)
> 	    "Passphrase for symmetric decryption: "
> 	  "GnuPG passphrase for %s: ")
> 	(or key-owner "??"))

In case of multiple private keys, then I won't be able to tell which
passphrase to input. So I still think this might be a bug.

I debug `pgg-gpg-decrypt-region' and found out the message-keys
returned by (pgg-decode-armor-region (point-min) (point-max)) is
something like "CF3FFFEF3FFF9B60A3FFF896D343FF8F" which has no way to
match the secret-keys because all of them are 8-char long.

I hope this is useful and thank you for looking into this.

regards,
-- 
Leo <sdl.web AT gmail.com>                         (GPG Key: 9283AA3F)

Re: [bug] PGG shows ?? when prompt for passphrase

[Daiki Ueno]

>>>>> In <m21wmzs1sk.fsf@sl392.st-edmunds.cam.ac.uk> 
>>>>>	Leo <sdl.web@gmail.com> wrote:
> In case of multiple private keys, then I won't be able to tell which
> passphrase to input. So I still think this might be a bug.

I agree with you that might be a bug.  However, I think we can't make
it perfect.  For example see the comment on the above,

;; XXX the user is stuck if they need to use the passphrase for
;;     any but the first secret key for which the message is
;;     encrypted.  ideally, we would incrementally give them a
;;     chance with subsequent keys each time they fail with one.

> I debug `pgg-gpg-decrypt-region' and found out the message-keys
> returned by (pgg-decode-armor-region (point-min) (point-max)) is
> something like "CF3FFFEF3FFF9B60A3FFF896D343FF8F" which has no way to
> match the secret-keys because all of them are 8-char long.

> I hope this is useful and thank you for looking into this.

I'm afraid I won't do it because of two reasons.

First, I think selecting a secret key for a PGP message is out of scope
of PGG.  It is a task of GnuPG.

Second, nowadays gpg-agent is the recommended way to input passphrases.
In that case, we don't need such a more-than-necessarily-complicated
stuff at all.

Regards,
-- 
Daiki Ueno

Re: [bug] PGG shows ?? when prompt for passphrase

[Leo]

* Daiki Ueno (2006-12-17 12:28 +0900) said:
  ^^^^^^^^^^
> Second, nowadays gpg-agent is the recommended way to input passphrases.
> In that case, we don't need such a more-than-necessarily-complicated
> stuff at all.

If this is intended, I'd like to move on to use gpg-agent. I found no
document in helping me set this up. Any ideas?

-- 
Leo <sdl.web AT gmail.com>                         (GPG Key: 9283AA3F)

Re: [bug] PGG shows ?? when prompt for passphrase

[Daiki Ueno]

>>>>> In <m2fybfduj4.fsf@sl392.st-edmunds.cam.ac.uk> 
>>>>>	Leo <sdl.web@gmail.com> wrote:
> > Second, nowadays gpg-agent is the recommended way to input passphrases.
> > In that case, we don't need such a more-than-necessarily-complicated
> > stuff at all.

> If this is intended, I'd like to move on to use gpg-agent. I found no
> document in helping me set this up. Any ideas?

* gpg-agent(1)

The usual way to run the agent is from the ~/.xsession file:

         eval `gpg-agent --daemon`

* emacs/man/pgg.texi

@defvar pgg-gpg-use-agent
When using GnuPG (gpg) as PGP scheme you can use @code{gpg-agent} for
caching@footnote{Actually @code{gpg-agent} does not cache passphrases
but private keys.  On the other hand, from a users point of view this
technical difference isn't visible.}.  If non-@code{nil} try to use a
running @code{gpg-agent}.  It defaults to @code{nil}.
-- 
Daiki Ueno

Re: [bug] PGG shows ?? when prompt for passphrase

[Leo]

* Daiki Ueno (2006-12-17 13:28 +0900) said:
  ^^^^^^^^^^
[...]
>> If this is intended, I'd like to move on to use gpg-agent. I found
>> no document in helping me set this up. Any ideas?
>
> * gpg-agent(1)
>
> The usual way to run the agent is from the ~/.xsession file:
>
>          eval `gpg-agent --daemon`
>
> * emacs/man/pgg.texi
>
> @defvar pgg-gpg-use-agent
> When using GnuPG (gpg) as PGP scheme you can use @code{gpg-agent} for
> caching@footnote{Actually @code{gpg-agent} does not cache passphrases
> but private keys.  On the other hand, from a users point of view this
> technical difference isn't visible.}.  If non-@code{nil} try to use a
> running @code{gpg-agent}.  It defaults to @code{nil}.

Thank you again. I will stay with epg for now.

My system doesn't setup gnupg2 properly, so i will let others test
this solution.

-- 
Leo <sdl.web AT gmail.com>                         (GPG Key: 9283AA3F)

Re: [bug] PGG shows ?? when prompt for passphrase

[Richard Stallman]

    * gpg-agent(1)

    The usual way to run the agent is from the ~/.xsession file:

	     eval `gpg-agent --daemon`

    * emacs/man/pgg.texi

    @defvar pgg-gpg-use-agent
    When using GnuPG (gpg) as PGP scheme you can use @code{gpg-agent} for
    caching@footnote{Actually @code{gpg-agent} does not cache passphrases
    but private keys.  On the other hand, from a users point of view this
    technical difference isn't visible.}.  If non-@code{nil} try to use a
    running @code{gpg-agent}.  It defaults to @code{nil}.

If we tell the users

    put

	 eval `gpg-agent --daemon`

    in your file ~/.xsession and in your file ~/.bash_profile,
    and customize pgg-gpg-use-agent to t in Emacs.

that seems insufficient.  We need to also tell people how to specify a
passphrase to gpg-agent, right?  What should they do?

Re: [bug] PGG shows ?? when prompt for passphrase

[Daiki Ueno]

>>>>> In <E1Gw73B-000521-DN@fencepost.gnu.org> 
>>>>>	Richard Stallman <rms@gnu.org> wrote:
> If we tell the users

>     put

> 	 eval `gpg-agent --daemon`

>     in your file ~/.xsession and in your file ~/.bash_profile,
>     and customize pgg-gpg-use-agent to t in Emacs.

> that seems insufficient.  We need to also tell people how to specify a
> passphrase to gpg-agent, right?  What should they do?

Well, if people have the above settings, gpg-agent itself (typically
through the pinentry program) ask them input their passphrases when
needed.

Should we add something like "if gpg-agent prompt you a passphrase, type
it carefully"?
-- 
Daiki Ueno

Re: [bug] PGG shows ?? when prompt for passphrase

[Daiki Ueno]

>>>>> In <E1GwhJI-0003jz-GI@fencepost.gnu.org> 
>>>>>	Richard Stallman <rms@gnu.org> wrote:
>     Well, if people have the above settings, gpg-agent itself (typically
>     through the pinentry program) ask them input their passphrases when
>     needed.

> Your text does not mention the pinentry program.  Does the user
> have to run that?  With ssh-agent, the user needs to run ssh-add.

gpg-agent internally calls pinentry.  The user does not need to run it
manually.

> Does

>     > 	 eval `gpg-agent --daemon`

> take care of all the interaction with the user?

Yes it does.
-- 
Daiki Ueno

pgg-encrypt is a pain in the neck

[Richard Stallman]

I started with the following text in my *mail* buffer:


====start====
Content-Type: text/plain; charset=ISO-8859-15
From: Richard Stallman <rms@gnu.org>
To: peterb
cc: rms
Subject: Testing
Reply-to: rms@gnu.org
--text follows this line--
this is a test.
====end====


and I did M-x pgg-encrypt.
It prompted for the recipients with no default.
(mailcrypt-encrypt gets defaults from the To and CC fields.)

So I entered `peterb, rms' by hand, and it encrypted the whole buffer
including the header.  It left nothing in the buffer except for
the encrypted text.  I verified by running gpg manually
that the encrypted text contained the mail buffer headers.
(mailcrypt-encrypt would have encrypted only the message body.)

To test pgg-decrypt, I encrypted that message with mailcrypt-encrypt,
which gave me the headers above plus a GPG message in the body.
Then I used pgg-decrypt.  It decrypted the body ok, but discarded
the headers entirely.

This is not an adequate replacement for mailcrypt, not as it currently
works.  We need to fix it now.

One way to fix pgg-encrypt would be to give it heuristics like the
ones mailcrypt-encrypt uses.  Another would be to declare pgg-encrypt
to be a "low level" interface, reliable for programs with no DWIM, and
define a different command for users to encrypt their messages.

What do you think should be done?

As for pgg-decrypt, it has to preserve everything in the buffer
aside from the encrypted text which it decrypts.

Re: pgg-encrypt is a pain in the neck

[Sascha Wilde]

Richard Stallman <rms@gnu.org> wrote:
Hi Richard,

[...]
> This is not an adequate replacement for mailcrypt, not as it currently
> works.  We need to fix it now.

AFAIK pgg was never meant to be a replacement for mailcrypt on its
own.  It was included with gnus and together with it (more specific:
message mode using MML) it builds a full blown, easy to use, mail
encryption tool -- but pgg one is not capable of much more than
en-/decrypting text using a OpenPGP backend (mostly GnuPG).

> One way to fix pgg-encrypt would be to give it heuristics like the
> ones mailcrypt-encrypt uses.  Another would be to declare pgg-encrypt
> to be a "low level" interface, reliable for programs with no DWIM, and
> define a different command for users to encrypt their messages.

PGG is rather "low level" in context of mail encryption, but please
bear in mind, that there are other uses for GnuPG: You can encrypt
other private or confidential stuff just to keep it safe without
sending it per mail, and that's where the currently available user
functions come in handy.

I agree, that a more generic solution might be worthwhile, but I don't
think that pgg is "broke" or needs to be "fixed" in this regard.

Btw. I think one source of this problem is that we currently have two
(or more?) mail composition modes in Emacs: message mode coming from
gnus and mail mode.  I'm quite certain, that there are more features
besides encryption which are only available in one of them.
Disclaimer, this is not intended to be a flame bait.  ;-)

cheers
sascha
-- 
Sascha Wilde : VI is to EMACS as masturbation is to making love:
             : effective and always available but probably not your
             : first choice...

Re: pgg-encrypt is a pain in the neck

[Daiki Ueno]

>>>>> In <m27iw9jhni.fsf@kenny.sha-bang.de> 
>>>>>	Sascha Wilde <wilde@sha-bang.de> wrote:
> > One way to fix pgg-encrypt would be to give it heuristics like the
> > ones mailcrypt-encrypt uses.  Another would be to declare pgg-encrypt
> > to be a "low level" interface, reliable for programs with no DWIM, and
> > define a different command for users to encrypt their messages.

> PGG is rather "low level" in context of mail encryption, but please
> bear in mind, that there are other uses for GnuPG: You can encrypt
> other private or confidential stuff just to keep it safe without
> sending it per mail, and that's where the currently available user
> functions come in handy.

I think it's not a bad idea to make pgg-encrypt (not pgg-encrypt-region)
use such a heuristics, and actually it's not hard to implement.

By the way, it could be a nightmare if mailcrypt were included right
now.  After a brief look at mailcrypt.el and mc-gpg.el, I found that it
has the same security problem which once PGG had, and currently no
support for gpg-agent.  We have to work on two different "low level"
(and not smart, I think) interfaces?
-- 
Daiki Ueno

Re: pgg-encrypt is a pain in the neck

[Sascha Wilde]

Daiki Ueno <ueno@unixuser.org> wrote:

> I think it's not a bad idea to make pgg-encrypt (not pgg-encrypt-region)
> use such a heuristics, and actually it's not hard to implement.

I agree, but don't know if it's TRTTD before the release.

cheers
sascha
-- 
Sascha Wilde
Wer HTML postet oder gepostetes HTML quotet oder sich gepostetes oder
gequotetes HTML beschafft, um es in Verkehr zu bringen, wird geplonkt.

Re: pgg-encrypt is a pain in the neck

[Reiner Steib]

On Sun, Dec 31 2006, Sascha Wilde wrote:

> Daiki Ueno <ueno@unixuser.org> wrote:
>
>> I think it's not a bad idea to make pgg-encrypt (not pgg-encrypt-region)
>> use such a heuristics, and actually it's not hard to implement.
>
> I agree, but don't know if it's TRTTD before the release.

How about adding two simple wrapper functions to `sendmail.el'?
`mail-encrypt-body' and `mail-decrypt-body'?

Something *similar* to the commands below.  I don't use Rmail and I'm
not sure if the use of PGG especially in `mail-decrypt-body' is the
right thing.  And probably there should be a command to replace the
encryped text with the decrypted text.

--8<---------------cut here---------------start------------->8---
(defun mail-narrow-to-body ()
  "Narrow to mail body, excluding mail headers."
  (goto-char (point-min))
  (narrow-to-region
   (progn
     (mail-text)
     (point))
   ;; Or (cf. `message-goto-body') ...
   ;; (or (search-forward (concat "\n" mail-header-separator "\n") nil t)
   ;;  (search-forward-regexp "[^:]+:\\([^\n]\\|\n[ \t]\\)+\n\n" nil t))
   (point-max)))

(defun mail-encrypt-body ()
  (interactive)
  (save-excursion
    (save-restriction
      (mail-narrow-to-body)
      (call-interactively 'pgg-encrypt))))

(defun mail-decrypt-body (&optional passphrase)
  (interactive)
  (save-excursion
    (save-restriction
      (mail-narrow-to-body)
      (if (apply 'pgg-decrypt-region (point-min) (point-max) passphrase)
	  (pop-to-buffer pgg-output-buffer)
	(pgg-display-error-buffer)))))
--8<---------------cut here---------------end--------------->8---

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

Re: pgg-encrypt is a pain in the neck

[Daiki Ueno]

>>>>> In <v9ac14w43t.fsf@marauder.physik.uni-ulm.de> 
>>>>>	Reiner Steib <reinersteib+gmane@imap.cc> wrote:
> >> I think it's not a bad idea to make pgg-encrypt (not pgg-encrypt-region)
> >> use such a heuristics, and actually it's not hard to implement.
> >
> > I agree, but don't know if it's TRTTD before the release.

> How about adding two simple wrapper functions to `sendmail.el'?
> `mail-encrypt-body' and `mail-decrypt-body'?

It looks better than my approach to changing pgg-encrypt and
pgg-decrypt.  Though it doesn't (yet?) support extracting default
recipients from To: or Cc: headers, now it could be easily complete,
borrowing some code from my patch.

Regards,
-- 
Daiki Ueno

Re: pgg-encrypt is a pain in the neck

[Richard Stallman]

    (defun mail-narrow-to-body ()
      "Narrow to mail body, excluding mail headers."
      (goto-char (point-min))
      (narrow-to-region
       (progn
	 (mail-text)
	 (point))
       ;; Or (cf. `message-goto-body') ...
       ;; (or (search-forward (concat "\n" mail-header-separator "\n") nil t)
       ;;  (search-forward-regexp "[^:]+:\\([^\n]\\|\n[ \t]\\)+\n\n" nil t))
       (point-max)))

    (defun mail-encrypt-body ()
      (interactive)
      (save-excursion
	(save-restriction
	  (mail-narrow-to-body)
	  (call-interactively 'pgg-encrypt))))

This looks like a good start.  However, instead
of using call-interactively to call pgg-encrypt, it should
read the argument itself, and supply a default based on
the addresses in the message.  You can find the code
to get those addresses in sendmail-send-it.

I think something similar is needed for pgg-sign,
so as to will sign just the message body and not the headers.

    (defun mail-decrypt-body (&optional passphrase)
      (interactive)
      (save-excursion
	(save-restriction
	  (mail-narrow-to-body)
	  (if (apply 'pgg-decrypt-region (point-min) (point-max) passphrase)
	      (pop-to-buffer pgg-output-buffer)
	    (pgg-display-error-buffer)))))

This would work fine in Mail mode, but it also needs to handle Rmail
mode.  Decrypting is done once in a while in Mail mode, but Rmail mode
is where it is usually done.

Daiki's code for decryption does more of the right thing.  That could
be put into a command called mail-decrypt, to avoid changing pgg
itself.

Re: pgg-encrypt is a pain in the neck

[Richard Stallman]

    PGG is rather "low level" in context of mail encryption, but please
    bear in mind, that there are other uses for GnuPG: You can encrypt
    other private or confidential stuff just to keep it safe without
    sending it per mail, and that's where the currently available user
    functions come in handy.

    I agree, that a more generic solution might be worthwhile, but I don't
    think that pgg is "broke" or needs to be "fixed" in this regard.

There seems to be a disagreement about this.  Daiki Ueno told me that
PGG could do what Mailcrypt does; I found it cannot, and you say it
isn't supposed to.

Your viewpoint seems to be that PGG is actually meant only for use
from other Lisp programs.  If so, I don't think it really needs to be
documented on its own.  If PGG is currently only useful via Gnus, then
I think the documentation of gpg-agent is only needed in the Gnus
manual, since it is only relevant for Gnus.  Could someone please install
the text that Daiki Ueno wrote into the Gnus manual?

Meanwhile, it is unfortunate that Emacs has most of what is needed to
do the job of Mailcrypt but fails to actually deliver that
functionality to the user.  I hope people will implement this, soon
after the release.

    Btw. I think one source of this problem is that we currently have two
    (or more?) mail composition modes in Emacs: message mode coming from
    gnus and mail mode.

I have always been unhappy with the Gnus developers for writing
another mail composition mode without discussing with me whether we
should have another.

Re: pgg-encrypt is a pain in the neck

[Sascha Wilde]

Richard Stallman <rms@gnu.org> wrote:

>     PGG is rather "low level" in context of mail encryption, but please
>     bear in mind, that there are other uses for GnuPG: You can encrypt
>     other private or confidential stuff just to keep it safe without
>     sending it per mail, and that's where the currently available user
>     functions come in handy.
>
>     I agree, that a more generic solution might be worthwhile, but I don't
>     think that pgg is "broke" or needs to be "fixed" in this regard.
>
> There seems to be a disagreement about this.  Daiki Ueno told me that
> PGG could do what Mailcrypt does; I found it cannot, and you say it
> isn't supposed to.

I can't speak for Daiki, but as I see it PGG on its own can't but
together with message mode it can, so this might be what he meant.

> Your viewpoint seems to be that PGG is actually meant only for use
> from other Lisp programs.

Not only from other Lisp programs, but mainly, yes.

> If so, I don't think it really needs to be documented on its own.

I don't think that documentation for library stuff is bad, and PGG is
not the only case: we have manuals for eg. Emacs MIME, URL, SMTP and
Widget, too.  And PGG _has_ interactive user functions which should be
documented. 

> If PGG is currently only useful via Gnus, then I think the
> documentation of gpg-agent is only needed in the Gnus manual, since
> it is only relevant for Gnus.

I don't think so.

1. As pointed out in my last mail: if you want to encrypt stuff
   independently from mail PGG _is_ useful on its own.

2. Mail encryption with PGG works in message mode, which can be used
   independently from Gnus and has it's own manual, too.

The message mode manual already refers to the PGG manual, so I don't
think any addition is needed.  But if you think we should urge the
users more explicit to use gpg-agent, then the message mode manual
would be the right place, IMHO.

> Could someone please install the text
> that Daiki Ueno wrote into the Gnus manual?

Please don't.  See above, why not.

> Meanwhile, it is unfortunate that Emacs has most of what is needed to
> do the job of Mailcrypt but fails to actually deliver that
> functionality to the user.  I hope people will implement this, soon
> after the release.

I agree, and as Daiki wrote it shouldn't be to hard to do.

On the other hand: maybe we should aim for merging mail mode and
message mode in long terms?

cheers
sascha
-- 
Sascha Wilde

"Unix was the first OS where you could carry the media and system
documentation around in a briefcase. This was fixed in BSD4.2."

Re: pgg-encrypt is a pain in the neck

[Daiki Ueno]

>>>>> In <m27iw8xm2u.fsf@kenny.sha-bang.de> 
>>>>>	Sascha Wilde <wilde@sha-bang.de> wrote:
> > There seems to be a disagreement about this.  Daiki Ueno told me that
> > PGG could do what Mailcrypt does; I found it cannot, and you say it
> > isn't supposed to.

> I can't speak for Daiki, but as I see it PGG on its own can't but
> together with message mode it can, so this might be what he meant.

It was my mistake that I answered to Richard's question with simply
"Yes".

What I meant was not "PGG's interactive commands behave exactly same as
Mailcrypt's interactive commands" but "things he wanted could be done
with PGG's interactive commands (with some basic commands)".  For
example, to encrypt a mail, people can do `C-x n n' to narrow to the
mail body and `M-x pgg-encrypt'.

However, I agree with that PGG's interactive commands sucks in usability.

> > Meanwhile, it is unfortunate that Emacs has most of what is needed to
> > do the job of Mailcrypt but fails to actually deliver that
> > functionality to the user.  I hope people will implement this, soon
> > after the release.

> I agree, and as Daiki wrote it shouldn't be to hard to do.

Here is the patch.  Though it might look not so trivial, it only changes
the interactive behavior of pgg-encrypt and pgg-decrypt so it should
bring no harm to other Lisp programs.

Index: lisp/pgg.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/pgg.el,v
retrieving revision 1.4
diff -c -r1.4 pgg.el
*** lisp/pgg.el	5 Sep 2006 08:17:35 -0000	1.4
--- lisp/pgg.el	31 Dec 2006 14:12:54 -0000
***************
*** 37,42 ****
--- 37,44 ----
  (eval-when-compile
    (require 'cl))
  
+ (require 'mail-utils)
+ 
  ;;; @ utility functions
  ;;;
  
***************
*** 367,373 ****
  
  If optional PASSPHRASE is not specified, it will be obtained from the
  passphrase cache or user."
!   (interactive (list (split-string (read-string "Recipients: ") "[ \t,]+")))
    (let* ((start (or start (point-min)))
  	 (end (or end (point-max)))
  	 (status (pgg-encrypt-region start end rcpts sign passphrase)))
--- 369,399 ----
  
  If optional PASSPHRASE is not specified, it will be obtained from the
  passphrase cache or user."
!   (interactive
!    (save-excursion
!      (let (recipients)
!        (goto-char (point-min))
!        (when (eq major-mode 'mail-mode)
! 	 (save-restriction
! 	   (narrow-to-region (point)
! 			     (progn
! 			       (search-forward mail-header-separator nil 0)
! 			       (match-beginning 0)))
! 	   (setq recipients
! 		 (mail-strip-quoted-names
! 		  (mapconcat #'identity
! 			     (nconc (mail-fetch-field "to" nil nil t)
! 				    (mail-fetch-field "cc" nil nil t)
! 				    (mail-fetch-field "bcc" nil nil t))
! 			     ","))))
! 	 (if recipients
! 	     (setq recipients (delete "" (split-string recipients "[ \t\n]+"))))
! 	 (goto-char (point-min))
! 	 (if (search-forward mail-header-separator nil t)
! 	     (forward-line)))
!        (list (or recipients
! 		 (split-string (read-string "Recipients: ") "[ \t,]+"))
! 	     nil (point) (point-max)))))
    (let* ((start (or start (point-min)))
  	 (end (or end (point-max)))
  	 (status (pgg-encrypt-region start end rcpts sign passphrase)))
***************
*** 400,412 ****
  
  If optional PASSPHRASE is not specified, it will be obtained from the
  passphrase cache or user."
!   (interactive "")
!   (let* ((start (or start (point-min)))
! 	 (end (or end (point-max)))
! 	 (status (pgg-decrypt-region start end passphrase)))
!     (when (interactive-p)
!       (pgg-display-output-buffer start end status))
!     status))
  
  ;;;###autoload
  (defun pgg-sign-region (start end &optional cleartext passphrase)
--- 426,455 ----
  
  If optional PASSPHRASE is not specified, it will be obtained from the
  passphrase cache or user."
!   (interactive)
!   (if (interactive-p)
!       (let (cipher status)
! 	(goto-char (point-min))
! 	(if (re-search-forward "-----BEGIN PGP MESSAGE-----$" nil t)
! 	    (setq start (match-beginning 0)
! 		  end (re-search-forward "^-----END PGP MESSAGE-----$" nil t)))
! 	(unless end
! 	  (error "No armor tail"))
! 	(setq cipher (buffer-substring start end))
! 	(with-temp-buffer
! 	  (insert cipher)
! 	  (setq status (pgg-decrypt-region (point-min) (point-max))))
! 	(if status
! 	    (if (y-or-n-p "Replace text? ")
! 		(let ((inhibit-read-only t)
! 		      buffer-read-only)
! 		  (pgg-situate-output start end))
! 	      (with-output-to-temp-buffer pgg-echo-buffer
! 		(set-buffer standard-output)
! 		(insert-buffer pgg-output-buffer)))
! 	  (pgg-display-error-buffer)))
!     (pgg-decrypt-region (or start (point-min)) (or end (point-max))
! 			passphrase)))
  
  ;;;###autoload
  (defun pgg-sign-region (start end &optional cleartext passphrase)

-- 
Daiki Ueno

Re: pgg-encrypt is a pain in the neck

[Richard Stallman]

    2. Mail encryption with PGG works in message mode, which can be used
       independently from Gnus and has it's own manual, too.

    The message mode manual already refers to the PGG manual, so I don't
    think any addition is needed.  But if you think we should urge the
    users more explicit to use gpg-agent, then the message mode manual
    would be the right place, IMHO.

Ok, point taken.  Would someone please install the gpg-agent
directions there?

It is important to give this advice explicitly _in_ the Emacs
documentation (at the appropriate places), because this recommendation
is for security purposes.

Re: pgg-encrypt is a pain in the neck

[Daiki Ueno]

>>>>> In <E1H18w2-0007Px-5V@fencepost.gnu.org> 
>>>>>	Richard Stallman <rms@gnu.org> wrote:
>     2. Mail encryption with PGG works in message mode, which can be used
>        independently from Gnus and has it's own manual, too.

>     The message mode manual already refers to the PGG manual, so I don't
>     think any addition is needed.  But if you think we should urge the
>     users more explicit to use gpg-agent, then the message mode manual
>     would be the right place, IMHO.

> Ok, point taken.  Would someone please install the gpg-agent
> directions there?

Do you mean "the gpg agent directions" is one I wrote?  You asked me to
write a documentation of gpg-agent usage for the Emacs Manual, and I
sent the following to you privately.

Some Emacs commands internally call GnuPG (the @command{gpg} command)
to perform data encryption, and in certain cases (decrypting or
signing for example), @command{gpg} requires user's passphrase.
Currently the recommended way to supply your passphrase to
@command{gpg} is to use the @command{gpg-agent} program.

To use @command{gpg-agent} in Emacs, you need to run the following
command from the shell before starting Emacs.

@example
eval `gpg-agent --daemon`
@end example

This will invoke @command{gpg-agent} and set the environment variable
@code{GPG_AGENT_INFO} to allow @command{gpg} to communicate with it.
It might be good idea to put this command in your @file{.xsession} or
@file{.bash_profile}.  @xref{Invoking GPG-AGENT, , , gnupg, Using the
GNU Privacy Guard}.

Once your @command{gpg-agent} is set up, it will ask you for a
passphrase as needed for @command{gpg}.  Under the X Window System,
you will see a new passphrase input dialog appear.  The dialog is
provided by PIN Entry (the @command{pinentry} command), and as of
version 0.7.2, @command{pinentry} cannot cooperate with Emacs on a
single tty.  So, if you are using a text console, you may need to put
a passphrase into gpg-agent's cache beforehand.  The following command
does the trick.

@example
gpg --use-agent --sign < /dev/null > /dev/null
@end example

The Lisp variable @code{pgg-gpg-use-agent} controls whether to use
@command{gpg-agent}.  See also @xref{Caching passphrase, , , pgg, The
PGG Manual}.

-- 
Daiki Ueno

Re: pgg-encrypt is a pain in the neck

[Richard Stallman]

    Do you mean "the gpg agent directions" is one I wrote?  You asked me to
    write a documentation of gpg-agent usage for the Emacs Manual, and I
    sent the following to you privately.

Yes, that is the text I mean.  Would someone please install this
in the Message mode manual?


Some Emacs commands internally call GnuPG (the @command{gpg} command)
to perform data encryption, and in certain cases (decrypting or
signing for example), @command{gpg} requires user's passphrase.
Currently the recommended way to supply your passphrase to
@command{gpg} is to use the @command{gpg-agent} program.

To use @command{gpg-agent} in Emacs, you need to run the following
command from the shell before starting Emacs.

@example
eval `gpg-agent --daemon`
@end example

This will invoke @command{gpg-agent} and set the environment variable
@code{GPG_AGENT_INFO} to allow @command{gpg} to communicate with it.
It might be good idea to put this command in your @file{.xsession} or
@file{.bash_profile}.  @xref{Invoking GPG-AGENT, , , gnupg, Using the
GNU Privacy Guard}.

Once your @command{gpg-agent} is set up, it will ask you for a
passphrase as needed for @command{gpg}.  Under the X Window System,
you will see a new passphrase input dialog appear.  The dialog is
provided by PIN Entry (the @command{pinentry} command), and as of
version 0.7.2, @command{pinentry} cannot cooperate with Emacs on a
single tty.  So, if you are using a text console, you may need to put
a passphrase into gpg-agent's cache beforehand.  The following command
does the trick.

@example
gpg --use-agent --sign < /dev/null > /dev/null
@end example

The Lisp variable @code{pgg-gpg-use-agent} controls whether to use
@command{gpg-agent}.  See also @xref{Caching passphrase, , , pgg, The
PGG Manual}.

Re: pgg-encrypt is a pain in the neck

[Reiner Steib]

On Tue, Jan 02 2007, Richard Stallman wrote:

>     Do you mean "the gpg agent directions" is one I wrote?  You asked me to
>     write a documentation of gpg-agent usage for the Emacs Manual, and I
>     sent the following to you privately.
>
> Yes, that is the text I mean.  Would someone please install this
> in the Message mode manual?

If it should go to the Message mode manual (I'm not sure about this,
because AFAIK allout.el also uses gpg-agent), we should install it in
(info "(message)Security").  But this node is already quite long, so I
suggest to split it like as follows (suggestions for improvements
welcome).  I've added the new text in the node "Using PGP/MIME".
[ Committed to Emacs CVS. ]

,----[ (info "(message)Security") ]
| 2.7 Security
| 
| Using the MML language, Message is able to create digitally signed and
| digitally encrypted messages.  Message (or rather MML) currently
| support PGP (RFC 1991), PGP/MIME (RFC 2015/3156) and S/MIME.
| 
| * Menu:
| 
| * Signing and encryption::     Signing and encrypting commands.
| * Using S/MIME::                Using S/MIME
| * Using PGP/MIME::              Using PGP/MIME
| * PGP Compatibility::           Compatibility with older implementations
`----

> Some Emacs commands internally call GnuPG (the @command{gpg} command)

I've changes this to "Message internally calls GnuPG ...".

> It might be good idea to put this command in your @file{.xsession} or
> @file{.bash_profile}.  @xref{Invoking GPG-AGENT, , , gnupg, Using the

Shouldn't this read @file{.profile}?

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

Re: pgg-encrypt is a pain in the neck

[Richard Stallman]

    On the other hand: maybe we should aim for merging mail mode and
    message mode in long terms?

I am in favor of the idea, generally speaking.  Emacs ought to have
only one such mode, which does all the things users want.

The people who implemented Message mode ought to have spoken with me
about what they found inadequate in Mail mode, so we could work out a
way to improve Mail mode.  But they did not discuss this with me; I
found out about it only after the fact.

We cannot change the past, but we can head in the right direction
in the future.

Re: pgg-encrypt is a pain in the neck

[Stefan Monnier]

> I am in favor of the idea, generally speaking.  Emacs ought to have
> only one such mode, which does all the things users want.

It's already in the etc/TODO file.


        Stefan

pgg-encrypt is a pain in the neck

[Richard Stallman]

I mailed myself a message containing encrypted text (see below)
and then in Rmail I did M-x pgg-decrypt.  It gave me an error
`Buffer is read only'.

mailcrypt-decrypt gives me the option of either replacing the
encrypted message text with the decrypted text, or viewing it
in another buffer.

I think pgg-decrypt, in order to be usable as a user-level
replacement command, needs to do the same.


Content-Type: text/plain; charset=ISO-8859-15
From: Richard Stallman <rms@gnu.org>
to: rms@gnu.org
Subject: Testing
Reply-to: rms@gnu.org
Date: Sat, 30 Dec 2006 13:24:20 -0500

-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.4-ecc0.1.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.6 <http://mailcrypt.sourceforge.net/>

hQIOA/3ra/q9cxsaEAf9ErrsaVQssI3SWRhKTSTh5SImrjPb7rxtAv7tQTiLDx07
4NhlMrPdR2dcfcHDKBi42CAucprH/3QvQS8HWmhLecsbMY0GVA8gczlleOjWZ7Wm
5ncIN0VNO+d60oxLRXs/n1lPX9pXAJ+pQa7Mb6EyYONi/8M7MI0QNr0wjgP1Lav8
4+vf/H/f/3vch46icr6K2r3ucdOLqyVXvl8L7ewNP98ON5iw7tASKwBdbeCmELvM
Q68Ak4coa5lwOQUWer79CF2K8YLKAt/ZSUuiKjyvr3fP20ZaTRMzntsuRmDO15ub
YvKlyLrEO5lh54Qhjm61VEgqCKdtRixUBEeDUbHWOgf9E+fFjIa4TX7RaHfR71zP
tYKZNl0Uh3+W2WkAMkmbTy0JmnjNbE9WQx7Tsglw6hfMpVON9NOoR3rQ/NazfqsD
IzbfrDh4uO5/B1zKUiOW0i8tEP1kntFh1XRDE5UVokP2TOYU6qI4D6TpIKO30QS3
QzMkkTGYbVakN65czoEW7wRbfOnXeVEvtzQxvaR1Zk60a4bo7mW/0GA7s7C4odus
2kbjcCAxLwaOHZugESHx2ItRYMCSEsQaFrYj7eR9oj8zYMYRqyX+TA0H2HOfI4SL
r0s55Cd4uzNSzMONmEhpnMzOXUV9EGy11Aqu2I3wNXCwfDz1fbA8fRMy2g8eBtAS
o4UBDgOHmnw3sbEO1hAEAL29ZaKeHJIl/FOZM01W78F9E4lSpxcuEETsxhUj+7pB
dRnolJf2T7uVSuSbZ3KCY16GdKhu/kZ7WlysazPf1jWHgWBkY9U9m30c+s1wTCPM
wyp0DVx/vjj78Re20iZzSONvrwNux8ciXvtwYRJiTGLCuv3MU6E4jMtNXRDKAmwF
BACylszugG+en056envEddaiyxR7BRMCMs3xrYZptNPnLSJZtELIJqcQRqLW05Qt
gdpDmGjH3D96fXHt4ybkce7Mc0sSr1uGzO331EPj9/SK5jf3Zc2cmGOC+LphJ0G7
aY9MoaR9/3DRPjftJaPiPGHNK72ScHLO1bQwsgnjr/nlANJLAZAZBhf/5+cnTnJ1
9uzjIm2xYADIAhepA0boa+FyXKDjjjSy+cbVvWKhJWTr5qXgWLybTVEaPlxYo+UF
oz0wZBHY0tg6+FPkdPA6
=rocE
-----END PGP MESSAGE-----

Re: Syncing Gnus and Emacs repositories

[Daiki Ueno]

>>>>> In <87ps303tzf.fsf@catnip.gol.com> 
>>>>>	Miles Bader <miles@gnu.org> wrote:
> Leo <sdl.web@gmail.com> writes:
> >> Indeed I (the author) did abandoned pgg*.el, and the Gnus trunk does
> >> not use them by default.
> >
> > If it is possible, let's just move to easypg, of which Daiki is also the
> > author.

> That can happen later.  For now let's just do the simple and
> straight-forward thing.

Perhaps.  However, it might be better to include EasyPG before synching
Gnus, because it has been the default PGP backend of the Gnus trunk for
one year and has been tested.  If we revert the pgg*.el, we will need to
wait a while for testing.

I also recalled a private conversation with Richard,

>>>>> In <E1H0Juj-0005YY-RU@fencepost.gnu.org> 
>>>>>	Richard Stallman <rms@gnu.org> wrote:
>     By the way, I'll propose addition of EasyPG http://www.easypg.org to
>     Emacs, after the release.  It is an all-in-one GnuPG interface and
>     hopefully a better replacement of mailcrypt, crypt++, encrypt.el, PGG,
>     gpg.el, gpg-ring.el, smime.el, etc.

> That might be a good idea, assuming all the developers want to sign
> papers.  Would you like to talk with them and see?

I'm willing to do that.

Regards,
-- 
Daiki Ueno

Re: Syncing Gnus and Emacs repositories

[Miles Bader]

Daiki Ueno <ueno@unixuser.org> writes:
>> That can happen later.  For now let's just do the simple and
>> straight-forward thing.
>
> Perhaps.  However, it might be better to include EasyPG before synching
> Gnus, because it has been the default PGP backend of the Gnus trunk for
> one year and has been tested.  If we revert the pgg*.el, we will need to
> wait a while for testing.

???

Since easypg isn't included in the gnus trunk or emacs trunk (how can it
be "the default" if it isn't included?), surely it would require testing
too.

-miles

-- 
x
y
Z!

Re: Syncing Gnus and Emacs repositories

[Daiki Ueno]

>>>>> In <87ejjf50pk.fsf@catnip.gol.com> 
>>>>>	Miles Bader <miles@gnu.org> wrote:
> Daiki Ueno <ueno@unixuser.org> writes:
> >> That can happen later.  For now let's just do the simple and
> >> straight-forward thing.
> >
> > Perhaps.  However, it might be better to include EasyPG before synching
> > Gnus, because it has been the default PGP backend of the Gnus trunk for
> > one year and has been tested.  If we revert the pgg*.el, we will need to
> > wait a while for testing.

> Since easypg isn't included in the gnus trunk or emacs trunk (how can it
> be "the default" if it isn't included?), surely it would require testing
> too.

What I mean by "the default" is that if EasyPG is installed Gnus will
give it precedence over PGG.  Since EasyPG is not a library exclusively
used by Gnus, it has been developped outside the Gnus repository.

The point is, if there are any points of the interface between Gnus and
PGG (as you said), we have to change the caller (i.e. Gnus) and it might
cause a new bug.  On the other hand, EasyPG does not need such a change.
If EasyPG is merged before the Gnus synch, users can continue to use
Gnus' PGP commands via EasyPG while fixing Gnus and PGG issues.

Regards,
-- 
Daiki Ueno

Re: Syncing Gnus and Emacs repositories

[Richard Stallman]

Please do talk with the easypg developers about merging it into Emacs.
However, Emacs and Gnus can't use it until that is done.

Re: Syncing Gnus and Emacs repositories

[Stefan Monnier]

>>> Indeed I (the author) did abandoned pgg*.el, and the Gnus trunk does
>>> not use them by default.
>> 
>> If it is possible, let's just move to easypg, of which Daiki is also the
>> author.

> That can happen later.  For now let's just do the simple and
> straight-forward thing.

Indeed, we're talking about switching the Emacs trunk's version og Gnus to
the Gnus trunk, not about changing the Gnus trunk.


        Stefan

Re: Syncing Gnus and Emacs repositories

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> That can happen later.  For now let's just do the simple and
>> straight-forward thing.
>
> Indeed, we're talking about switching the Emacs trunk's version og Gnus to
> the Gnus trunk, not about changing the Gnus trunk.

Yes, but I really want the code in both to be as similar as possible.  I
could just toss out the new pgg*.el stuff when merging, but then Gnus
may stop working with pgg in Emacs.  Given that pgg in the Gnus trunk is
pretty much a lame duck anyway, it seems a lot saner to just get things
into a good and mergeable state in the Gnus trunk and then merge it into
Emacs with minimal changes.

-Miles

-- 
Is it true that nothing can be known?  If so how do we know this?  -Woody Allen

Re: Syncing Gnus and Emacs repositories

[Richard Stallman]

    Yes, but I really want the code in both to be as similar as possible.  I
    could just toss out the new pgg*.el stuff when merging, but then Gnus
    may stop working with pgg in Emacs.

Why would it not work with the pgg in Emacs?
The former Gnus code did.  Restoring both pgg*
and the callers of it as they were before
(when this code was put into Emacs before)
is the easiest thing to do.

Re: Syncing Gnus and Emacs repositories

[Richard Stallman]

    > Indeed I (the author) did abandoned pgg*.el, and the Gnus trunk does
    > not use them by default.

Why doesn't it?  Since pgg*.el are now a standard part of Emacs, it
makes sense for Gnus to use them.

What does it use instead?

    If it is possible, let's just move to easypg, of which Daiki is also the
    author.

That is a much bigger change, which we'd have to think about.

Re: Syncing Gnus and Emacs repositories

[Daiki Ueno]

>>>>> In <E1I8SW9-0002tE-9R@fencepost.gnu.org> 
>>>>>	Richard Stallman <rms@gnu.org> wrote:
>     > Indeed I (the author) did abandoned pgg*.el, and the Gnus trunk does
>     > not use them by default.

> Why doesn't it?  Since pgg*.el are now a standard part of Emacs, it
> makes sense for Gnus to use them.

Because that is the only advantage of PGG.  I'm aware of many
limitations of PGG.

- PGG can't handle a message signed with multiple keys.
- PGG can't prompt a user which key is being used.
- PGG can't create a binary PGP messages.
- PGG doesn't provide a way to select keys per cryptographic operation.
- PGG ignores GnuPG's trust metrics.
- PGG can't integrate well with mail-mode.
- etc.

Frankly, (at least) I don't want to extend PGG to support these issues,
because that requires almost rewrite of the slightly outdated code
(actually, PGG is my first elisp program written about 10 years ago ;-)

> What does it use instead?

EasyPG.  If it is available, Gnus automatically detects it.

>     If it is possible, let's just move to easypg, of which Daiki is also the
>     author.

> That is a much bigger change, which we'd have to think about.

I think that is not so big change.  Because it requires just 7 files
(epg*.el, epa*.el) to be included.

Regards,
-- 
Daiki Ueno

Re: Syncing Gnus and Emacs repositories

[Sascha Wilde]

Daiki Ueno <ueno@unixuser.org> wrote:
[...]
> Frankly, (at least) I don't want to extend PGG to support these issues,
> because that requires almost rewrite of the slightly outdated code
> (actually, PGG is my first elisp program written about 10 years ago ;-)
>
>> What does it use instead?
>
> EasyPG.  If it is available, Gnus automatically detects it.

In general I agree that replacing PGG is TRTTD.  I haven't had time to
look at EasyPG yet, but some questions come to my mind: 

- are the features I added to PGG (symmetric encryption, use of
  gpg-agent) already in EasyPG?

- how does EasyPG communicate with gpg?

  The (strongly) recommended way to utilizes gpg in applications is
  using the gpgme api (or maybe the assuan protocol directly, but I'm
  not sure about this, I added Werner Koch to the CC, so he might
  comment on this).

  It would be great if EasyPG would do just that.

- Is there any S/MIME support in EasyPG?
  As gpg supports S/MIME since version 2.x this would be a great
  enhancement.

cheers
sascha
-- 
Sascha Wilde 
- no sig today... sorry!

Re: Syncing Gnus and Emacs repositories

[Daiki Ueno]

>>>>> In <m2abu3i8kb.fsf@kenny.sha-bang.de> 
>>>>>	Sascha Wilde <wilde@sha-bang.de> wrote:
> Daiki Ueno <ueno@unixuser.org> wrote:
> [...]
> > Frankly, (at least) I don't want to extend PGG to support these issues,
> > because that requires almost rewrite of the slightly outdated code
> > (actually, PGG is my first elisp program written about 10 years ago ;-)
> >
> >> What does it use instead?
> >
> > EasyPG.  If it is available, Gnus automatically detects it.

> In general I agree that replacing PGG is TRTTD.  I haven't had time to
> look at EasyPG yet, but some questions come to my mind: 

> - are the features I added to PGG (symmetric encryption, use of
>   gpg-agent) already in EasyPG?

Yes, but the implementation is different.

> - how does EasyPG communicate with gpg?

>   The (strongly) recommended way to utilizes gpg in applications is
>   using the gpgme api (or maybe the assuan protocol directly, but I'm
>   not sure about this, I added Werner Koch to the CC, so he might
>   comment on this).

You didn't look into the source code of GPGME, did you?  GPGME just
invokes "gpg" or "gpgsm" commands and communicates with them in the same
way as EasyPG does.

> - Is there any S/MIME support in EasyPG?
>   As gpg supports S/MIME since version 2.x this would be a great
>   enhancement.

Already there.  Gnus interface is also available.

Regards,
-- 
Daiki Ueno

Re: Syncing Gnus and Emacs repositories

[Richard Stallman]

    I think that is not so big change.  Because it requires just 7 files
    (epg*.el, epa*.el) to be included.

That is a big change.

If we install epg*, can we replace pgg* with a simple
interface to epg*?

Re: Syncing Gnus and Emacs repositories

[Miles Bader]

Reiner Steib <reinersteib+gmane@imap.cc> writes:
> IMHO, now it would more sense to merge these changes to EMACS_22_BASE
> (the 22.x release branch in Emacs' repository) instead.  Changes in
> v5-10 are only bug- and doc-fixes, so we should have all these changes
> in Emacs 22.2 as well.
>
> Miles, could you arrange this (unless there are objections)?

Sure.

-Miles

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