Re: [mail.list.steel.mental@gmail.com: chinese group names can not displayed properly in *Complation* buffer]

Re: [mail.list.steel.mental@gmail.com: chinese group names can not displayed properly in *Complation* buffer]

[Richard Stallman]

    The non-ASCII group names handling of Gnus was much improved in
    the Gnus CVS trunk[1], not in the v5-10 branch which is being
    synchronized with Emacs CVS.

Should the Gnus trunk version go into the Emacs trunk?

Syncing Gnus and Emacs repositories (was: [mail.list.steel.mental@gmail.com: chinese group names can not displayed properly in *Complation* buffer])

[Reiner Steib]

On Mon, Oct 01 2007, Richard Stallman wrote:

>     The non-ASCII group names handling of Gnus was much improved in
>     the Gnus CVS trunk[1], not in the v5-10 branch which is being
>     synchronized with Emacs CVS.
>
> Should the Gnus trunk version go into the Emacs trunk?

Yes, this is what we plan to do.  (Cf. the thread "Syncing Gnus and
Emacs repositories" back in June.)  Due to the problems with Miles
internet connection an some issues about PGG this hasn't happened yet.

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

Re: Syncing Gnus and Emacs repositories (was: [mail.list.steel.mental@gmail.com: chinese group names can not displayed properly in *Complation* buffer])

[Richard Stallman]

    > Should the Gnus trunk version go into the Emacs trunk?

    Yes, this is what we plan to do.  (Cf. the thread "Syncing Gnus and
    Emacs repositories" back in June.)  Due to the problems with Miles
    internet connection an some issues about PGG this hasn't happened yet.

Can't you do this without Miles?

Re: Syncing Gnus and Emacs repositories

[Reiner Steib]

On Tue, Oct 02 2007, Richard Stallman wrote:

>     > Should the Gnus trunk version go into the Emacs trunk?
>
>     Yes, this is what we plan to do.  (Cf. the thread "Syncing Gnus and
>     Emacs repositories" back in June.)  Due to the problems with Miles
>     internet connection an some issues about PGG this hasn't happened yet.
>
> Can't you do this without Miles?

As a one-time-shot: probably yes (if someone has the time to do it).
But I'm not sure if this would later cause extra work for Miles.  And
we need to fix the PGG issues first (I need to look into this, and
will do).

But for a permanent sync, we need a semi-automatic process
(e.g. Miles' sync via arch).  (Please change the subject, when turning
this thread into some general version control system discussion).

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

Re: Syncing Gnus and Emacs repositories

[Daiki Ueno]

2007/10/2, Reiner Steib <reinersteib+gmane@imap.cc>:
> On Tue, Oct 02 2007, Richard Stallman wrote:
>
> >     > Should the Gnus trunk version go into the Emacs trunk?
> >
> >     Yes, this is what we plan to do.  (Cf. the thread "Syncing Gnus and
> >     Emacs repositories" back in June.)  Due to the problems with Miles
> >     internet connection an some issues about PGG this hasn't happened yet.
> >
> > Can't you do this without Miles?
>
> As a one-time-shot: probably yes (if someone has the time to do it).
> But I'm not sure if this would later cause extra work for Miles.  And
> we need to fix the PGG issues first (I need to look into this, and
> will do).

IIUC, it is Miles who knows what the issues are.

Regards,
-- 
Daiki Ueno

Re: Syncing Gnus and Emacs repositories

[Richard Stallman]

    IIUC, it is Miles who knows what the issues are.

If there are issues about installing the new Gnus version into Emacs,
Don't the Gnus developers know what these issues are?

Have you tried running the latest Gnus in the current trunk Emacs?
Does it work?

Re: Syncing Gnus and Emacs repositories

[Daiki Ueno]

2007/10/3, Richard Stallman <rms@gnu.org>:
>     IIUC, it is Miles who knows what the issues are.
>
> If there are issues about installing the new Gnus version into Emacs,
> Don't the Gnus developers know what these issues are?

Hopefully.  But Miles said that he tried test-merge and he encountered
several issues about PGG, and he couldn't remember the issues were.
How do we can know his issues?

> Have you tried running the latest Gnus in the current trunk Emacs?
> Does it work?

I believe so.  However, I stop using Gnus for daily work and I can't
tell whether there are really issues about PGG or not.  Reiner Steib
and Katsumi Yamaoka also said that they rarely use Gnus' PGP
functions.

Therefore we need a tester who keeps track on cvs.gnus.org, replaces
Gnus' pgg*.el with Emacs', uses Gnus' PGP functions for daily work,
and has not yet switched to EasyPG.

It looks like a ridiculous situation for me...

Regards,
-- 
Daiki Ueno

Re: Syncing Gnus and Emacs repositories

[Leo]

On 2007-10-03 12:09 +0100, Daiki Ueno wrote:
> Therefore we need a tester who keeps track on cvs.gnus.org, replaces
> Gnus' pgg*.el with Emacs', uses Gnus' PGP functions for daily work,
> and has not yet switched to EasyPG.

Someone probably RMS should decide what to do with the situation. The
discussion has been going on for ages.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

       Use the most powerful email client -- http://gnus.org/

Re: Syncing Gnus and Emacs repositories

[Reiner Steib]

On Wed, Oct 03 2007, Leo wrote:

> On 2007-10-03 12:09 +0100, Daiki Ueno wrote:
>> Therefore we need a tester who keeps track on cvs.gnus.org, replaces
>> Gnus' pgg*.el with Emacs', uses Gnus' PGP functions for daily work,
>> and has not yet switched to EasyPG.

As neither Gnus trunk nor Emacs trunk are going to be released soon, I
think we can risk to break something temporally.  (Both are
development versions after all.)

> Someone probably RMS should decide what to do with the situation. The
> discussion has been going on for ages.

Nobody volunteered to work on it (during my vacation), see
<http://thread.gmane.org/gmane.emacs.gnus.general/64959/focus=65116>.
I will work on it now.

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

Re: Syncing Gnus and Emacs repositories

[Leo]

On 2007-10-03 14:41 +0100, Reiner Steib wrote:
> On Wed, Oct 03 2007, Leo wrote:
>
>> On 2007-10-03 12:09 +0100, Daiki Ueno wrote:
>>> Therefore we need a tester who keeps track on cvs.gnus.org, replaces
>>> Gnus' pgg*.el with Emacs', uses Gnus' PGP functions for daily work,
>>> and has not yet switched to EasyPG.
>
> As neither Gnus trunk nor Emacs trunk are going to be released soon, I
> think we can risk to break something temporally.  (Both are
> development versions after all.)

Agree.

>
>> Someone probably RMS should decide what to do with the situation. The
>> discussion has been going on for ages.
>
> Nobody volunteered to work on it (during my vacation), see
> <http://thread.gmane.org/gmane.emacs.gnus.general/64959/focus=65116>.
> I will work on it now.

Thanks.

>
> Bye, Reiner.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

       Use the most powerful email client -- http://gnus.org/

Re: Syncing Gnus and Emacs repositories

[Richard Stallman]

    Hopefully.  But Miles said that he tried test-merge and he encountered
    several issues about PGG, and he couldn't remember the issues were.
    How do we can know his issues?

If he does not remember them, he could not tell you anything about
them, even if he were available.

So you may as well just do the best you can.  Nobody else can do
better.

    I believe so.  However, I stop using Gnus for daily work and I can't
    tell whether there are really issues about PGG or not.  Reiner Steib
    and Katsumi Yamaoka also said that they rarely use Gnus' PGP
    functions.

Install the new version and we will see if there are any problems.
Also, by and by we will install EasyPG.  We want to do this.

Re: Syncing Gnus and Emacs repositories

[Reiner Steib]

On Tue, Oct 02 2007, Richard Stallman wrote:

> Have you tried running the latest Gnus in the current trunk Emacs?
> Does it work?

I run latest Gnus trunk and EMACS_22_BASE.  Several others use Gnus
trunk and Emacs trunk.  I don't expect major problems.

On Thu, Oct 04 2007, Richard Stallman wrote:
>     I believe so.  However, I stop using Gnus for daily work and I can't
>     tell whether there are really issues about PGG or not.  Reiner Steib
>     and Katsumi Yamaoka also said that they rarely use Gnus' PGP
>     functions.

I have made the required changes in Gnus trunk (revert PGG to the
version in Emacs) on 2007-10-03; no complains yet.

> Install the new version and we will see if there are any problems.

I assume you refer to the new Gnus version here (i.e. sync Gnus trunk
to Emacs trunk).  This could be done now, when someone finds time to
do it.

> Also, by and by we will install EasyPG.  We want to do this.

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:
> I have made the required changes in Gnus trunk (revert PGG to the
> version in Emacs) on 2007-10-03; no complains yet.
>
>> Install the new version and we will see if there are any problems.
>
> I assume you refer to the new Gnus version here (i.e. sync Gnus trunk
> to Emacs trunk).  This could be done now, when someone finds time to
> do it.

Ok, I will try it again.

-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

[Richard Stallman]

    As a one-time-shot: probably yes (if someone has the time to do it).
    But I'm not sure if this would later cause extra work for Miles.

Why is Miles specially relevant here?

We have no idea how long Miles will be unable to do this, so I think
we need to prepare to go on with work even in his absence.

Re: Syncing Gnus and Emacs repositories

[Reiner Steib]

On Tue, Oct 02 2007, Richard Stallman wrote:

>     As a one-time-shot: probably yes (if someone has the time to do it).
>     But I'm not sure if this would later cause extra work for Miles.
>
> Why is Miles specially relevant here?

Miles has volunteered to sync Gnus and Emacs.  I'm unsure if a
one-time-shot sync would cause him extra work.  If so, I'd prefer to
avoid it.

> We have no idea how long Miles will be unable to do this, so I think
> we need to prepare to go on with work even in his absence.

Stefan offered help for syncing Emacs branches [1].  If Stefan also
would like to help syncing Gnus and Emacs, I'm sure he could get write
access to Gnus repository.

Bye, Reiner.

[1] 
,----[ http://thread.gmane.org/gmane.emacs.devel/80166 ]
| From: Stefan Monnier <monnier@iro.umontreal.ca>
| Subject: miles@gnu.org
| Newsgroups: gmane.emacs.devel
| To: emacs-devel@gnu.org
| Date: Wed, 03 Oct 2007 03:18:29 -0400
| Message-ID: <jwv4ph8y8g2.fsf-monnier+emacs@gnu.org>
| 
| Hi Miles,
| 
| Seeing how you're having trouble with your connection, I was thinking that
| I could maybe help you with keeing the various branches in sync.
| 
| Could you send me the script(s) as well as any extra info you can think of
| which would allow me to do that job you used to do (and still do
| occasionally, of course)?
| 
|         Stefan
`----
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

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.

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.

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: 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.