MAINTAINERS file

MAINTAINERS file

[Nick Roberts]

I can't pretend that I've always enjoyed RMS' autocratic leadership style but
it was certainly unambiguous and clear, and showed enormous stamina covering
most questions raised on the list.  Now that he's stepping down, it's not
clear, to me at least, what the rules are and if Stefan and Yidong are going
maintain Emacs in the same manner.  Already changes appear to be being made
more freely and I feel it could become chaotic.

Therefore, I suggest that the MAINTAINERS file is resurrected and areas of
Emacs identified for which responsible maintainers are found.  To some extent
this is done aleady and and it would merely formalise the arrangement.  This is
probably only necessary for core (C source) Emacs development, and perhaps
fundamental lisp development, e.g., byte compiler, subr.el, and lisp packages
could be maintained in their usual way.  By way of example, it might be
helpful to look at the MAINTAINERS file for Gdb or Gcc, although these are
probably too elaborate for Emacs current needs.  I think such a file would also
make Stefan and Yidong's task less onerous.

Just my two cents.

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

Re: MAINTAINERS file

[Karl Fogel]

Nick Roberts <nickrob@snap.net.nz> writes:
> I can't pretend that I've always enjoyed RMS' autocratic leadership
> style but it was certainly unambiguous and clear, and showed enormous
> stamina covering most questions raised on the list.  Now that he's
> stepping down, it's not clear, to me at least, what the rules are and
> if Stefan and Yidong are going maintain Emacs in the same manner.
> Already changes appear to be being made more freely and I feel it
> could become chaotic.
>
> Therefore, I suggest that the MAINTAINERS file is resurrected and
> areas of Emacs identified for which responsible maintainers are found.
> To some extent this is done aleady and and it would merely formalise
> the arrangement.  This is probably only necessary for core (C source)
> Emacs development, and perhaps fundamental lisp development, e.g.,
> byte compiler, subr.el, and lisp packages could be maintained in their
> usual way.  By way of example, it might be helpful to look at the
> MAINTAINERS file for Gdb or Gcc, although these are probably too
> elaborate for Emacs current needs.  I think such a file would also
> make Stefan and Yidong's task less onerous.
>
> Just my two cents.

Could you identify the specific problems you think might arise without
a MAINTAINERS file?

You use "chaotic" pejoratively, but I'm not necessarily convinced :-).
It really depends on the kind of chaos (if any).  Many projects
operate without area maintainers, and do just fine.  Having area
maintainers can lead to gumption-thwarting territoriality and
unnecessary power relationships (I'm not saying power relationships
are always bad, but unnecessary ones are).

Let's wait until there's a problem before imposing a solution like
this.

-Karl

Re: MAINTAINERS file

[Miles Bader]

Karl Fogel <kfogel@red-bean.com> writes:
> Let's wait until there's a problem before imposing a solution like
> this.

Indeed.  I think Emacs has done pretty well with the basic rule
"Don't be an idiot, and if you're not sure, ask the list first."

People sometimes make mistakes, but by and large it seems to work out.

-miles

-- 
"Whatever you do will be insignificant, but it is very important that
 you do it."  Mahatma Gandhi

Re: MAINTAINERS file

[Andreas Röhler]

Am Freitag, 29. Februar 2008 08:05 schrieb Miles Bader:
> Karl Fogel <kfogel@red-bean.com> writes:
> > Let's wait until there's a problem before imposing a solution like
> > this.
>
> Indeed.  I think Emacs has done pretty well with the basic rule
> "Don't be an idiot, and if you're not sure, ask the list first."
>
> People sometimes make mistakes, but by and large it seems to work out.
>
> -miles


As with any succession principles of development are
not as implicit--not to say incorporated--as it's now,
I'd welcome a discussion around that.

It might provide useful information in many respects.

Andreas Röhler

Re: MAINTAINERS file

[Juanma Barranquero]

On Fri, Feb 29, 2008 at 8:05 AM, Miles Bader <miles.bader@necel.com> wrote:

>  Indeed.  I think Emacs has done pretty well with the basic rule
>  "Don't be an idiot, and if you're not sure, ask the list first."

And the implicit corollary: "If you're an idiot and don't ask the list
first, don't worry; someone will take care of letting you know." :)

             Juanma

Re: MAINTAINERS file

[Bastien]

Miles Bader <miles.bader@necel.com> writes:

> "Don't be an idiot, and if you're not sure, ask the list first."

What does that mean?

-- 
Bastien

Re: MAINTAINERS file

[Juanma Barranquero]

On Fri, Feb 29, 2008 at 12:25 PM, Bastien <bzg@altern.org> wrote:

>  > "Don't be an idiot, and if you're not sure, ask the list first."
>
>  What does that mean?

"Use common sense."
"Don't act too hastily."
"Consider consequences."
"Don't change for change's sake."
"Learn from the past."
...

             Juanma

Re: MAINTAINERS file

[Bastien Guerry]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On Fri, Feb 29, 2008 at 12:25 PM, Bastien <bzg@altern.org> wrote:
>
>>  > "Don't be an idiot, and if you're not sure, ask the list first."
>>
>>  What does that mean?
>
> "Use common sense."
> "Don't act too hastily."
> "Consider consequences."
> "Don't change for change's sake."
> "Learn from the past."
> ...

"Check for humour in questions."
...

-- 
Bastien

Re: MAINTAINERS file

[Juanma Barranquero]

On Fri, Feb 29, 2008 at 12:50 PM, Bastien Guerry <Bastien.Guerry@ens.fr> wrote:

>  "Check for humour in questions."

Hmm... "Check for humour in answers" would apply here too, I think...

             Juanma

Re: MAINTAINERS file

[Bastien]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On Fri, Feb 29, 2008 at 12:50 PM, Bastien Guerry <Bastien.Guerry@ens.fr> wrote:
>
>>  "Check for humour in questions."
>
> Hmm... "Check for humour in answers" would apply here too, I think...

:)

I guess I missed a chance to become the area maintainer for DEVEL.HUMOR
and JOKES.  If I don't, consider I'm officially applying for this.

-- 
Bastien

Re: MAINTAINERS file

[Juanma Barranquero]

On Fri, Feb 29, 2008 at 1:05 PM, Bastien <bzg@altern.org> wrote:

>  I guess I missed a chance to become the area maintainer for DEVEL.HUMOR
>  and JOKES.  If I don't, consider I'm officially applying for this.

Please! :)

At the moment I'm the only one who adds to DEVEL.HUMOR; sometimes I've
been tempted to rename it YOU'RE-TOO-EASILY-AMUSED-JUANMA.

             Juanma

Re: MAINTAINERS file

[Miles Bader]

Bastien <bzg@altern.org> writes:
>> "Don't be an idiot, and if you're not sure, ask the list first."
>
> What does that mean?

It means if you feel unsure whether you're doing the right thing, ask
the list first.  Don't make unannounced changes outside your area of
expertise.  If you need to ask "what does it mean to be sure?" then it
means you're not sure. :-]

Most Emacs hackers start out asking the list about every little change,
and slowly develop a feeling for what things they need to ask about, and
what things they don't.  As Juanma said, when someone goes too fast and
starts making bad changes without asking, there are many on this list
who will happily take care of letting them know.  :-)

Of course the above system only works when peope are reasonable, but I
think everybody currently hacking on Emacs has proven to be quite
reasonable.

-Miles

-- 
"Most attacks seem to take place at night, during a rainstorm, uphill,
 where four map sheets join."   -- Anon. British Officer in WW I

Re: MAINTAINERS file

[Xavier Maillard]

   Karl Fogel <kfogel@red-bean.com> writes:
   > Let's wait until there's a problem before imposing a solution like
   > this.

   Indeed.  I think Emacs has done pretty well with the basic rule
   "Don't be an idiot, and if you're not sure, ask the list first."

   People sometimes make mistakes, but by and large it seems to work out.

I second that. As a simple lurker, what I see seems very clean
and natural.

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Re: MAINTAINERS file

[Glenn Morris]

Karl Fogel wrote:

> Nick Roberts <nickrob@snap.net.nz> writes:
[...]
>> Therefore, I suggest that the MAINTAINERS file is resurrected and
[...]
> Could you identify the specific problems you think might arise without
> a MAINTAINERS file?

In case there's any confusion, just to say that the MAINTAINERS file
hasn't gone away. It's sitting in the admin directory, where I think
something like that belongs.

Re: MAINTAINERS file

[Nick Roberts]

 > Could you identify the specific problems you think might arise without
 > a MAINTAINERS file?

For a start there are now two maintainers instead of one, so it would be
helpful to know how their roles are divided.  I guess the MAINTAINERS file need
not contain any more than this.  OTOH, if Stefan and Yidong are not going to
maintain Emacs like Richard, i.e. with complete authority and complete
coverage, then authority needs to be devolved.  (Disclaimer: I have
no interest in becoming an area maintainer).

 > You use "chaotic" pejoratively, but I'm not necessarily convinced :-).
 > It really depends on the kind of chaos (if any).  Many projects
 > operate without area maintainers, and do just fine.  Having area
 > maintainers can lead to gumption-thwarting territoriality and
 > unnecessary power relationships (I'm not saying power relationships
 > are always bad, but unnecessary ones are).

Chaos is never favourable, although anarchy may sometimes be.  Someone has
to always arbitrate over any disagreement.

 > Let's wait until there's a problem before imposing a solution like
 > this.

Like what?  There always has been a power structure for Emacs but I guess up
till now it's been so simple that it didn't need writing down before.

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

Re: MAINTAINERS file

[Karl Fogel]

Nick Roberts <nickrob@snap.net.nz> writes:
> Chaos is never favourable, although anarchy may sometimes be.  Someone has
> to always arbitrate over any disagreement.

This is not true.  For example, in the Subversion project there is no
arbitrator.  We try for consensus, and if there is unresolveable
disagreement, the global committers vote.

A vote has happened only twice in the history of the project:

   - To decide on the name of the command line binary ("sub" vs "svn")

   - To decide whether we would put a space before the opening
     parenthesis when writing C function calls and definitions. 

I think this is evidence that consensus, with democracy as a fallback,
can work pretty well! :-)

>  > Let's wait until there's a problem before imposing a solution like
>  > this.
>
> Like what?  There always has been a power structure for Emacs but I
> guess up till now it's been so simple that it didn't need writing
> down before.

A power structure is not needed, when you have revision control (so
changes can be undone) and forkability (so dissenters are never
trapped).

You might ask: what then is Chen and Stefan's role?

Answer: default moral authority to prevent bandwidth-consuming votes
for every little dispute.  If enough of us grant them the right to
make judgement calls (and I certainly intend to abide by their
judgement when I'm unable to convince them of something), then the
project will run efficiently and they will have the ability to enforce
consistency on the codebase.

This is the only authority RMS ever had, really.  Being root on the
repository and mailing list servers is not decisive: it cannot prevent
a fork if people are determined to fork.  The consent of the
"governed" is the only thing that makes this work, in the end.  It has
done the job up till now, and I see no reason why it can't continue.
There's no reason for us to put potentially costly dispute-resolution
structures in place in anticipation of problems that may never arise.

-Karl

Re: MAINTAINERS file

[Karl Fogel]

Karl Fogel <kfogel@red-bean.com> writes:
> You might ask: what then is Chen and Stefan's role?

Sorry.  This was a double typo: first, it's "Chong" not "Chen", and it
should have been "Yidong" anyway.  (Sigh, I even speak and read some
Chinese -- but when names are written in Roman letters and I've never
seen the characters I have a hard time remembering what's what!)

My apologies, Yidong.  对不起 :-)

-Karl

Re: MAINTAINERS file

[Chong Yidong]

Karl Fogel <kfogel@red-bean.com> writes:

> Karl Fogel <kfogel@red-bean.com> writes:
>> You might ask: what then is Chen and Stefan's role?
>
> Sorry.  This was a double typo: first, it's "Chong" not "Chen", and it
> should have been "Yidong" anyway.  (Sigh, I even speak and read some
> Chinese -- but when names are written in Roman letters and I've never
> seen the characters I have a hard time remembering what's what!)
>
> My apologies, Yidong.  对不起 :-)

No worries.

Re: MAINTAINERS file

[Nick Roberts]

 > > Chaos is never favourable, although anarchy may sometimes be.  Someone has
 > > to always arbitrate over any disagreement.
 > 
 > This is not true.  For example, in the Subversion project there is no
 > arbitrator.  We try for consensus, and if there is unresolveable
 > disagreement, the global committers vote.
 > 
 > A vote has happened only twice in the history of the project:

That sounds like arbitration to me, but it certainly appears that the Subversion
project is fortunate in that disagreement doesn't often occur.

In any case, there doesn't appear to be much support for a written constiution
(AKA MAINTAINERS file).

So be it.

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

Re: MAINTAINERS file

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Date: Fri, 29 Feb 2008 17:34:54 -0500
> Cc: emacs-devel@gnu.org
> 
> Nick Roberts <nickrob@snap.net.nz> writes:
> > Chaos is never favourable, although anarchy may sometimes be.  Someone has
> > to always arbitrate over any disagreement.
> 
> This is not true.  For example, in the Subversion project there is no
> arbitrator.  We try for consensus, and if there is unresolveable
> disagreement, the global committers vote.

So in your case, the vote by the global committers is that ``someone''
whom Nick calls ``arbitrator''.  Thus, ``this is not true'' above is,
well, not true.

> A vote has happened only twice in the history of the project:
> 
>    - To decide on the name of the command line binary ("sub" vs "svn")
> 
>    - To decide whether we would put a space before the opening
>      parenthesis when writing C function calls and definitions. 
> 
> I think this is evidence that consensus, with democracy as a fallback,
> can work pretty well! :-)

One evidence, maybe.

> A power structure is not needed, when you have revision control (so
> changes can be undone) and forkability (so dissenters are never
> trapped).

So you think that commit/revert wars and forks are a better
alternative than clear, agreed-upon rules?

> You might ask: what then is [Yidong's] and Stefan's role?
> 
> Answer: default moral authority to prevent bandwidth-consuming votes
> for every little dispute.

By this, you actually suggested specific guidelines for managing the
project.  But these guidelines must be discussed and agreed to, in
order for them to become Emacs project's guidelines rather than Karl
Fogel's guidelines.  Otherwise, why would you think that you and I see
Yidong's and Stefan's leadership eye to eye?

> There's no reason for us to put potentially costly dispute-resolution
> structures in place in anticipation of problems that may never arise.

How do you know it is ``potentially costly'' without hearing specific
proposals, let alone trying them?

Re: MAINTAINERS file

[Karl Fogel]

Eli Zaretskii <eliz@gnu.org> writes:
>> This is not true.  For example, in the Subversion project there is no
>> arbitrator.  We try for consensus, and if there is unresolveable
>> disagreement, the global committers vote.
>
> So in your case, the vote by the global committers is that ``someone''
> whom Nick calls ``arbitrator''.  Thus, ``this is not true'' above is,
> well, not true.

If by "arbitrator" he merely meant "some means of resolving disputes
when consensus cannot be reached", then sure.  But that's not the
definition of "arbitrator" that most of the world uses, I think.

An arbitrator is a person or standing committee that makes decisions
when agreement cannot be reached among a larger group.  An arbitrator
is not necessarily a member of the group for which the decision is
being made (though may be, and in this case would be).

When the entire larger group votes, the word for that is "democracy",
and it is distinguishable from arbitration by these properties:
everyone is involved equally, and the decision-making processes is
transparent.  Neither of those need be true for arbitration.

>> A power structure is not needed, when you have revision control (so
>> changes can be undone) and forkability (so dissenters are never
>> trapped).
>
> So you think that commit/revert wars and forks are a better
> alternative than clear, agreed-upon rules?

At this point I have to roll my eyes.  Sorry, I hadn't realized we
were operating at the level of rhetoric used in U.S. presidental
campaigns rather than that used on free software development lists.

Sigh.

-Karl

Re: MAINTAINERS file

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Date: Sat, 01 Mar 2008 10:52:59 -0500
> Cc: emacs-devel@gnu.org
> 
> > So you think that commit/revert wars and forks are a better
> > alternative than clear, agreed-upon rules?
> 
> At this point I have to roll my eyes.  Sorry, I hadn't realized we
> were operating at the level of rhetoric used in U.S. presidental
> campaigns rather than that used on free software development lists.

I take that as a somewhat strange expression of unwillingness to
continue this discussion, and will respect that unwillingness.

Re: MAINTAINERS file

[Richard Stallman]

In the GNU Project, every package has a maintainer or maintainers who
are responsible for it.  They make the decisions on behalf of the GNU
Project.  They can delegate to others when they think that is best,
but they cannot give up the responsibility, except to hand it back
to the GNU Project.

Re: MAINTAINERS file

[Stefan Monnier]

To tell you the truth, I don't think we know yet how things will run.
But here's how I see it:
- as a maintainer, I have the responsability to make sure bug reports do
  not get lost.  That's my #1 preoccupation for now.  Which also means:
  please report bugs to emacsbugs.donarmstrong.com, please subscribe the
  the emacsbugs mailing list, and please respond to bugs on that
  mailing list rather than on the emacs-pretest-bug or
  bug-gnu-emacs lists.

- I do not intend to set up any new rules and procedures.

- I think Chong generally agrees.


        Stefan

Re: MAINTAINERS file

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sun, 02 Mar 2008 00:24:12 -0500
> Cc: emacs-devel@gnu.org
> 
> 
> To tell you the truth, I don't think we know yet how things will run.
> But here's how I see it:
> - as a maintainer, I have the responsability to make sure bug reports do
>   not get lost.  That's my #1 preoccupation for now.  Which also means:
>   please report bugs to emacsbugs.donarmstrong.com, please subscribe the
>   the emacsbugs mailing list, and please respond to bugs on that
>   mailing list rather than on the emacs-pretest-bug or
>   bug-gnu-emacs lists.
> 
> - I do not intend to set up any new rules and procedures.
> 
> - I think Chong generally agrees.

What about setting some development goals and stating some features
that you'd like to see added in the near future?  Also, what about
some approximate release plans, perhaps including major features that
should go into each one?  IOW, some general roadmap of Emacs
development?

Re: MAINTAINERS file

[Stefan Monnier]

> What about setting some development goals and stating some features
> that you'd like to see added in the near future?  Also, what about
> some approximate release plans, perhaps including major features that
> should go into each one?  IOW, some general roadmap of Emacs
> development?

My main objective will be to reduce the time between releases.
For the Emacs-22 branch, I do not have any particular intentions:
22.2 should come out soonish and after that, we'll see if there's time
and/or need for 22.3.

But the focus will be on 23.1.  As mentioned I'd like to enter feature
freeze for 23.1 by the beginning of the summer.  Until then I mostly
hope to include Emacs.app.

For 24 I'd like to include the lexbind branch.


        Stefan

Re: MAINTAINERS file

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> But the focus will be on 23.1.  As mentioned I'd like to enter feature
> freeze for 23.1 by the beginning of the summer.  Until then I mostly
> hope to include Emacs.app.

You have a mac, right?

-Miles

-- 
Christian, n. One who follows the teachings of Christ so long as they are not
inconsistent with a life of sin.

Re: MAINTAINERS file

[Stefan Monnier]

>> But the focus will be on 23.1.  As mentioned I'd like to enter feature
>> freeze for 23.1 by the beginning of the summer.  Until then I mostly
>> hope to include Emacs.app.
> You have a mac, right?

Check my User-Agent lines.


        Stefan

Re: MAINTAINERS file

[Romain Francoise]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> But the focus will be on 23.1.  As mentioned I'd like to enter feature
> freeze for 23.1 by the beginning of the summer.  Until then I mostly
> hope to include Emacs.app.

Do you see the SCM switch (to bzr) happening before or after 23.1?

Re: MAINTAINERS file

[Juanma Barranquero]

On Mon, Mar 3, 2008 at 1:55 PM, Romain Francoise <romain@orebokech.com> wrote:

>  Do you see the SCM switch (to bzr) happening before or after 23.1?

And, it is decided then that it *will* be to Bazaar?

             Juanma

Re: MAINTAINERS file

[Stefan Monnier]

>> Do you see the SCM switch (to bzr) happening before or after 23.1?
> And, it is decided then that it *will* be to Bazaar?

Not really, but I don't think it matters that much which one we choose,


        Stefan

Re: MAINTAINERS file

[Juanma Barranquero]

>  Not really, but I don't think it matters that much which one we choose,

It could matter. If the Windows support is not good, for example.

             Juanma

Re: MAINTAINERS file

[Karl Fogel]

"Juanma Barranquero" <lekktu@gmail.com> writes:
> On Mon, Mar 3, 2008 at 1:55 PM, Romain Francoise <romain@orebokech.com> wrote:
>>  Do you see the SCM switch (to bzr) happening before or after 23.1?
>
> And, it is decided then that it *will* be to Bazaar?

Please, yes :-).  Stefan's right, it doesn't really matter, any of the
distributed VCSs will be good for the Emacs team.

http://bazaar-vcs.org/ for more information.

We are not likely to regret it, and if we do, we can always try
something else.

(Note: I'm a Subversion developer, but agree that a distributed system
will be better for this particular development community.)

-Karl

Re: MAINTAINERS file

[Juanma Barranquero]

On Mon, Mar 3, 2008 at 5:51 PM, Karl Fogel <kfogel@red-bean.com> wrote:

>  Please, yes :-).  Stefan's right, it doesn't really matter, any of the
>  distributed VCSs will be good for the Emacs team.

Well, I mostly agree. I have no axe to grind, dVCS-wise. My "axe" is
more towards the tool being somewhat Windows-friendly.

I know that most, if not all of them, run on Windows; I've tried
bazaar, git, mercurial and darcs. I'm more worried about CRLF
conversion issues (AFAIK, bazaar has no support for automatic
conversion, but I'd love to be wrong about it) and whether ssh or
other authentication methods for write access are available on the
Windows ports.

>  (Note: I'm a Subversion developer, but agree that a distributed system
>  will be better for this particular development community.)

I think we know who you are, Karl ;-)

             Juanma

Re: MAINTAINERS file

[Jason Rumney]

Juanma Barranquero wrote:
> (AFAIK, bazaar has no support for automatic
> conversion, but I'd love to be wrong about it)

That lack of support could be a blessing in disguise. The only downside 
I can see is when adding new text files from Windows, you'll need to 
make sure they have Unix line ends before committing them.

Re: MAINTAINERS file

[Leo]

On 2008-03-03 17:32 +0000, Jason Rumney wrote:
> That lack of support could be a blessing in disguise. The only
> downside I can see is when adding new text files from Windows,
> you'll need to make sure they have Unix line ends before committing
> them.

Maybe permissions as well. A few days ago I spotted a file with wrong
permissions.

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

          Use the best OS -- http://www.fedoraproject.org/

Re: MAINTAINERS file

[Juanma Barranquero]

On Mon, Mar 3, 2008 at 6:32 PM, Jason Rumney <jasonr@gnu.org> wrote:

>  That lack of support could be a blessing in disguise. The only downside
>  I can see is when adding new text files from Windows, you'll need to
>  make sure they have Unix line ends before committing them.

And that's why it is not a blessing. You'll be exchanging a suit of
mistakes by a different one.

             Juanma

Re: MAINTAINERS file

[Jason Rumney]

Juanma Barranquero wrote:
> On Mon, Mar 3, 2008 at 6:32 PM, Jason Rumney <jasonr@gnu.org> wrote:
>
>   
>>  That lack of support could be a blessing in disguise. The only downside
>>  I can see is when adding new text files from Windows, you'll need to
>>  make sure they have Unix line ends before committing them.
>>     
>
> And that's why it is not a blessing. You'll be exchanging a suit of
> mistakes by a different one.
>   

Creating new files is not as common as the problems we encounter now 
with CVS. And if the version control system is not changing line ends 
behind your back, fixing such problems is a simple matter of checking in 
an updated version.

Re: MAINTAINERS file

[Juanma Barranquero]

On Mon, Mar 3, 2008 at 11:07 PM, Jason Rumney <jasonr@gnu.org> wrote:

>  Creating new files is not as common as the problems we encounter now
>  with CVS.

Yes. But that's because CVS is particularly bad in that regard.

             Juanma

Re: MAINTAINERS file

[Stefan Monnier]

>> That lack of support could be a blessing in disguise. The only downside
>> I can see is when adding new text files from Windows, you'll need to
>> make sure they have Unix line ends before committing them.

> And that's why it is not a blessing. You'll be exchanging a suit of
> mistakes by a different one.

Indeed, but I don't think it matters which set of mistakes we get.
I do think it's important that the VCS we end up choosing supports
Windows better than Arch does, but EOL-conversion is not needed.


        Stefan

Re: MAINTAINERS file

[Juanma Barranquero]

On Mon, Mar 3, 2008 at 11:28 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:

>  Indeed, but I don't think it matters which set of mistakes we get.

There must be a reason why all dVCS either do support eol conversion,
or are in the process of adding them...

>  I do think it's important that the VCS we end up choosing supports
>  Windows better than Arch does, but EOL-conversion is not needed.

Time will tell.

             Juanma

Re: MAINTAINERS file

[Stefan Monnier]

>> Indeed, but I don't think it matters which set of mistakes we get.
> There must be a reason why all dVCS either do support eol conversion,
> or are in the process of adding them...

It's probably important in general, but in the case of Emacs you can
expect that every developer will use an editor that can work (and will
properly preserve) either line end.


        Stefan

Re: MAINTAINERS file

[Juanma Barranquero]

On Mon, Mar 3, 2008 at 11:55 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:

>  It's probably important in general, but in the case of Emacs you can
>  expect that every developer will use an editor that can work (and will
>  properly preserve) either line end.

The same cannot be said of make programs, for example.

But it's no use arguing it. We'll have plenty of time to rejoice or lament.

             Juanma

Re: MAINTAINERS file

[paul r]

2008/3/3, Karl Fogel <kfogel@red-bean.com>:
> "Juanma Barranquero" <lekktu@gmail.com> writes:
>
> > On Mon, Mar 3, 2008 at 1:55 PM, Romain Francoise <romain@orebokech.com> wrote:
>  >>  Do you see the SCM switch (to bzr) happening before or after 23.1?
>  >
>  > And, it is decided then that it *will* be to Bazaar?
>

as a person considering to enter into emacs development one day, this
really is an important step.
I did a fairly complete audit last week of DVCS solutions that could
suit emacs need, and it turned out that, both from the technical point
of view, and for the emacs people tastes, bzr and hg (mercurial) meet
requirements and are almost indistinguishable products. Darcs is an
other one, fairly different, but mature and written in Haskell.

sorry for the noise if it has been largely discussed before.

paul

Re: MAINTAINERS file

[Richard Stallman]

We should use Bzr because that is becoming a GNU package.
GNU packages should show loyalty to each other when possible,
and in this case it is possible.

Re: MAINTAINERS file

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> We should use Bzr because that is becoming a GNU package.
> GNU packages should show loyalty to each other when possible,
> and in this case it is possible.

Is there an Emacs bzr repository yet?  My main concerns are the speed
and the size of the local data (the emacs source tree being a bit
hefty).

Thanks,

-Miles

-- 
Genealogy, n. An account of one's descent from an ancestor who did not
particularly care to trace his own.

Re: MAINTAINERS file

[Richard Stallman]

    Is there an Emacs bzr repository yet?  My main concerns are the speed
    and the size of the local data (the emacs source tree being a bit
    hefty).

No, but now that Bzr is running on Savannah, it would be nice to set
one up.

Re: MAINTAINERS file

[Stefan Monnier]

>     Is there an Emacs bzr repository yet?  My main concerns are the speed
>     and the size of the local data (the emacs source tree being a bit hefty).

> No, but now that Bzr is running on Savannah, it would be nice to set one up.

Indeed, that would be helpful.


        Stefan

Re: MAINTAINERS file

[Glenn Morris]

Richard Stallman wrote:

> No, but now that Bzr is running on Savannah

Are you sure about that? There's no information related to Bzr
anywhere on the Savannah website, AFAICS.

Re: MAINTAINERS file

[Richard Stallman]

    > No, but now that Bzr is running on Savannah

    Are you sure about that?

The main Savannah operator told me so, and I trust him.

			     There's no information related to Bzr
    anywhere on the Savannah website, AFAICS.

It is "experimental, not really supported".

Is there info missing that one would need in order to use Bzr on
Savannah?  If so, I will ask them to publish it.

Re: MAINTAINERS file

[Stefan Monnier]

>> No, but now that Bzr is running on Savannah
>     Are you sure about that?

> The main Savannah operator told me so, and I trust him.

> 			     There's no information related to Bzr
>     anywhere on the Savannah website, AFAICS.

> It is "experimental, not really supported".

> Is there info missing that one would need in order to use Bzr on
> Savannah?  If so, I will ask them to publish it.

To the extend that (like Arch) Bzr can use just `sftp' to read&write
a remote repository, I guess that there's no need for anything special,
other than a location.  Using a subdir of
arch.sv.gnu.org:/archives/emacs will work, but it's ugly.


        Stefan

Re: MAINTAINERS file

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Is there info missing that one would need in order to use Bzr on
>> Savannah?  If so, I will ask them to publish it.
>
> To the extend that (like Arch) Bzr can use just `sftp' to read&write a
> remote repository, I guess that there's no need for anything special,
> other than a location.  Using a subdir of
> arch.sv.gnu.org:/archives/emacs will work, but it's ugly.

Is the resulting server fully functional/fast?

-Miles

-- 
Everywhere is walking distance if you have the time.  -- Steven Wright

Re: MAINTAINERS file

[Stefan Monnier]

>>> Is there info missing that one would need in order to use Bzr on
>>> Savannah?  If so, I will ask them to publish it.
>> 
>> To the extend that (like Arch) Bzr can use just `sftp' to read&write a
>> remote repository, I guess that there's no need for anything special,
>> other than a location.  Using a subdir of
>> arch.sv.gnu.org:/archives/emacs will work, but it's ugly.

> Is the resulting server fully functional/fast?

As far as I can tell it's fully functional.  W.r.t the performance, it
seems acceptable and I'd expect it to be comparable to the performance
of Arch in similar circumstances.  But they also offer a "smart server"
which "performs certain operations much faster than dumb servers are
capable of".


        Stefan

Re: MAINTAINERS file

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> As far as I can tell it's fully functional.  W.r.t the performance, it
> seems acceptable and I'd expect it to be comparable to the performance
> of Arch in similar circumstances.

Arch is way too slow in general...

-Miles

-- 
Happiness, n. An agreeable sensation arising from contemplating the misery of
another.

Re: MAINTAINERS file

[Stefan Monnier]

>> As far as I can tell it's fully functional.  W.r.t the performance, it
>> seems acceptable and I'd expect it to be comparable to the performance
>> of Arch in similar circumstances.
> Arch is way too slow in general...

Agreed.  Hopefully bzr-over-sftp is only as slow as Arch w.r.t the
actual network access, and all the subsequent operations are a good
bit faster.


        Stefan

Re: MAINTAINERS file

[Thomas Lord]

[-- Attachment #1: Type: text/plain, Size: 1637 bytes --]

Stefan Monnier wrote:
>>> As far as I can tell it's fully functional.  W.r.t the performance, it
>>> seems acceptable and I'd expect it to be comparable to the performance
>>> of Arch in similar circumstances.
>>>       
>> Arch is way too slow in general...
>>     
>
> Agreed.  Hopefully bzr-over-sftp is only as slow as Arch w.r.t the
> actual network access, and all the subsequent operations are a good
> bit faster.
>   

Disk space is pretty cheap:  make sure you have a "revision library set
up".   If you are importing (or quickly creating) a lot of "history," be
sure to create cached revisions on the archive-side to speed-up
first-time check-outs.   Maybe people already know all that but it was
my experience that many times when people complain about arch being
slow, they haven't taken those steps.

Arch is "heavier" than other systems and, in some ways, is basically
"doing more" (than, e.g., git) so, yes, it won't win prizes for commit
times any soon.      In some ways that's a work-style issue.   Arch isn't
intended to be used in a mode where, for example, you commit every
time you save an editor file.    The "zen" of Arch is that each commit
should represent a kind of "complete thought" so that the record of
changesets is a kind of documentation of the logical steps that were
taken in the evolution of a branch.   If you find yourself doing commits
more than at most a few times per hour, and you're not doing something
special like plowing through a bunch of trivial merges, then you might
not be using it to its best effect.

(Yes, the above is about Arch but I assume it is still applicable to
bzr).

-t



[-- Attachment #2: Type: text/html, Size: 2284 bytes --]

Re: MAINTAINERS file

[Thomas Lord]

[-- Attachment #1: Type: text/plain, Size: 557 bytes --]

Thomas Lord wrote:
> The "zen" of Arch is that each commit
> should represent a kind of "complete thought" so that the record of
> changesets is a kind of documentation of the logical steps that were
> taken in the evolution of a branch.


Maybe someone should create a blog host where blog
posts are automatically generated from Arch (or bzr, whatever)
commit messages (with links to the patch and to the source tree
for the revision).   That should be pretty easy to do and might
a convenient "browser" for branches that are central to the project.

-t



[-- Attachment #2: Type: text/html, Size: 1004 bytes --]

Re: MAINTAINERS file

[Miles Bader]

Thomas Lord <lord@emf.net> writes:
> Arch is "heavier" than other systems and, in some ways, is basically
> "doing more" (than, e.g., git) so, yes, it won't win prizes for commit
> times any soon.

Geez, don't be silly Tom.  The problem is that the arch implementation
plays bugger-all attention to efficiency, whereas git has had many
people rabidly obsessing over every possible aspect of efficiency for
years...

Nothing to do with functionality.

-Miles

-- 
"Nah, there's no bigger atheist than me.  Well, I take that back.
I'm a cancer screening away from going agnostic and a biopsy away
from full-fledged Christian."  [Adam Carolla]

Re: MAINTAINERS file

[Thomas Lord]

[-- Attachment #1: Type: text/plain, Size: 2825 bytes --]

Miles Bader wrote:
> Thomas Lord <lord@emf.net> writes:
>   
>> Arch is "heavier" than other systems and, in some ways, is basically
>> "doing more" (than, e.g., git) so, yes, it won't win prizes for commit
>> times any soon.
>>     
>
> Geez, don't be silly Tom.  The problem is that the arch implementation
> plays bugger-all attention to efficiency, 

That's nonsense and (unintentionally, I assume) insulting.

It pays quite a bit of attention to performance.



> whereas git has had many
> people rabidly obsessing over every possible aspect of efficiency for
> years...
>   

There is some old mailing list message from Linus, around the
time git was launched, that drives most of that.   His very narrow
aim (in the area it differs from Arch) was to make "commit"
times as quick as possible.   That was, more or less, his specific
excuse for not using arch rather than writing git.

Commit times are a strange metric to optimize for in a changeset-oriented
system.   There are plenty of other design goals and constraints to
consider.

Why not look at check-out times or file retrieval times?
In many situations, for Arch, those are between O(1)
and O(n) where n is the number of bytes in the revision?

Or, if you really want git-speed (or better) commit times
for arch -- that can be done with some *modest* coding
by "committing to the revision library" and computing
the changeset more lazily.   (It'll still be slower than git
since it's tracking file and directory logical identities to
deal with renames reasonably, but it can be very fast.
With a slightly more than modest approach you can probably
even arrange to be usefully lazy about that and surpass git
commit speeds.    The big latencies in Arch are all about
duplicating repositories (or fetching them in lieu of)
and one-time costs of filling out caches.  I still maintain that
Arch imposes those costs at reasonable points in a reasonable
work-flow on top of sane configurations of Arch.

A weakness of Arch is that it is possible to use it poorly
in ways that its performance contours punish.  A
related weakness is that, if you approach Arch expecting it
to work like other systems, then you will be inclined to
use it poorly in ways that its performance contours punish.
So, it's not a dummy-proof program, by a long shot.


> Nothing to do with functionality.
>
>   

A lot to do with (a) bizarre hype about revision
control tech w/in the open source world;  (b) a culture
of hacking in the open source world that generates
work habits that don't easily give way to thinking about
"changeset blogging" as a mode of revision control.
(I use "open source" here deliberately to refer to a
popular development methodology culture.  Sadly,
most free software seems to be developed using
what popular opinion takes to be "open source
methods".)


-t


[-- Attachment #2: Type: text/html, Size: 3788 bytes --]

Re: MAINTAINERS file

[Miles Bader]

Thomas Lord <lord@emf.net> writes:
>> Geez, don't be silly Tom.  The problem is that the arch implementation
>> plays bugger-all attention to efficiency, 
>
> That's nonsense and (unintentionally, I assume) insulting.
>
> It pays quite a bit of attention to performance.

No insult was intended.  I like arch, I think it was a great design
(I still use tla daily!), and I have great respect for you.

However, in practice, tla often feels more like a proof-of-concept than
something which has had real attention paid to performance and
optimization.  Git development _has_ paid real attention to performance,
and it really shows.

[I'm not attempting to distinguish between inherent slowness (where
speed is hobbled by the underlying design) and lack of optimization,
merely observing that in practice, tla is slow.  No doubt there are
elements of both involved.]

> There is some old mailing list message from Linus, around the
> time git was launched, that drives most of that.   His very narrow
> aim (in the area it differs from Arch) was to make "commit"
> times as quick as possible.   That was, more or less, his specific
> excuse for not using arch rather than writing git.
>
> Commit times are a strange metric to optimize for in a changeset-oriented
> system.   There are plenty of other design goals and constraints to
> consider.
>
> Why not look at check-out times or file retrieval times?
> In many situations, for Arch, those are between O(1)
> and O(n) where n is the number of bytes in the revision?

I'm not talking about commit times.  I'm talking about basically _every_
operation which I do on a regular basic (e.g. update working dir, merge
other branch, do file/tree diff, commit) .  Git is really, _really_
fast.  Scary fast.  Tla is almost always palpably "slow", even when the
repository is on local disk and the revision library has every
applicable revision.  I still use, of course, so obviously it's in the
realm of "acceptable", but I've become accustomed to waiting.

> Or, if you really want git-speed (or better) commit times
> for arch -- that can be done with some *modest* coding
> by "committing to the revision library" and computing
> the changeset more lazily.

I'm sure there are many things that could be done to optimize tla and
speed things up.  Indeed, mostly what I'm trying to say is that
by-and-large, that work _hasn't been done_ on tla, and it _has_ been
done on git, and this fact is very obvious when using these systems.

In part this is a historical accident -- git happened to come of age in
a community where there are lots and lots of performance-obsessed people
well acquainted with the things you need to do to really make things
fast (and of course it's no accident that it's _fastest_ on a system
with a linux kernel...), and willing to put in the effort to make it so.

-Miles

-- 
Any man who is a triangle, has thee right, when in Cartesian Space, to
have angles, which when summed, come to know more, nor no less, than
nine score degrees, should he so wish.  [TEMPLE OV THEE LEMUR]

Re: MAINTAINERS file

[Thomas Lord]

Stefan Monnier wrote:
> To the extend that (like Arch) Bzr can use just `sftp' to read&write
> a remote repository, I guess that there's no need for anything special,
> other than a location.  Using a subdir of
> arch.sv.gnu.org:/archives/emacs will work, but it's ugly.
>   


Just to brag:  Arch's "dumb archive" architecture let's an archive
be hosted by sftp or ftp:  no arch-specific program has to be installed
and operated on the server side -- only some commonly available,
file-system-style service.

Relying on only "dumb servers" was a design constraint from the
earliest days of Arch.   The constraint was deliberately adopted to
achieve a goal:  to make it easier for people to "deploy" arch without
requiring cooperation from a third party.   For example,  that sftp is
already an option on a host makes it easier to deploy arch on that host,
without any change needed from the host operator.

It's nice to see that pay off *internally* to the GNU project but that's a
happy accident.   The original thought was more banal:  it's easier and
cheaper for people to find themselves an FTP or SFTP host than it is
for them to provision a personal host on which to install and operate
a version control system server.   I was thinking of "basement hackers"
who could maybe get a gratis FTP site, but couldn't get a gratis place
to install a revision control server that they themselves controlled.  Or,
at least, an (S)FTP site would be cheaper for a basement hacker.   I also
worried about the so-called "dissident" problem: piggy-backing on "dumb 
services"
makes it easier for people to publish source code even in circumstances
where permission would seek to require yet not offer itself.

The original thought was that centralized project sites like Savannah
and Sourceforge might fade away (or, rather, morph into more
"Freshmeat"-style services).   That's part of the reason I'm so
flummoxed by "Launchpad," which seems a complete inversion of the
original aims of Arch.

-t

Re: MAINTAINERS file

[Richard Stallman]

    > Is there info missing that one would need in order to use Bzr on
    > Savannah?  If so, I will ask them to publish it.

    To the extend that (like Arch) Bzr can use just `sftp' to read&write
    a remote repository, I guess that there's no need for anything special,
    other than a location.  Using a subdir of
    arch.sv.gnu.org:/archives/emacs will work, but it's ugly.

Is that the normal, recommended way to use Bzr?
If not, let's do it the normal, recommended way.
After all, we want everyone to be able to get the sources
easily from Bzr.

savannah-hackers can tell you whatever data you need
in order to do that.

Re: MAINTAINERS file

[Jason Earl]

Miles Bader <miles@gnu.org> writes:

> Richard Stallman <rms@gnu.org> writes:
>> We should use Bzr because that is becoming a GNU package.
>> GNU packages should show loyalty to each other when possible,
>> and in this case it is possible.
>
> Is there an Emacs bzr repository yet?  My main concerns are the speed
> and the size of the local data (the emacs source tree being a bit
> hefty).
>
> Thanks,

I've been experimenting importing the Emacs CVS repository into Bazaar.
In fact, I am currently using Bazaar's cvsps-import plugin to import the
entire CVS repository.  So far the process has taken about a week on the
(not very impressive) hardware I have available.

I've actually been working on this as a side project for about a month
and I have tried several different import methods, including a previous
attempt at using cvsps-import.  My last try was unsuccessful, but I
think I have worked out the problems.  That's encouraging, because
cvsps-import is incremental and would allow people to try bzr in the
same way that they can try the unofficial git repository.  I played
around for some time with a repository that was *nearly* complete and it
weighed in at around 450 M (with all branches).

My original plan was to pipe up on the lists *after* I had something
that I knew worked, but I'm pretty close, and I thought I might save
someone the trouble of duplicating my efforts.

Jason Earl

Re: MAINTAINERS file

[Stefan Monnier]

> I played around for some time with a repository that was *nearly*
> complete and it weighed in at around 450 M (with all branches).

Hmm... that sounds like it's a bit bigger than git's, right?

Then again, for my typical use (where I always have 3-4 branches checked
out at the same time), bzr's ability to share a repository among several
branches would make up for that difference.


        Stefan

Re: MAINTAINERS file

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I played around for some time with a repository that was *nearly*
>> complete and it weighed in at around 450 M (with all branches).
>
> Hmm... that sounds like it's a bit bigger than git's, right?

A fresh checkout uses 187 MB (all branches) for the git data (the entire
working directory, including the git data, is 289 MB).

> Then again, for my typical use (where I always have 3-4 branches
> checked out at the same time), bzr's ability to share a repository
> among several branches would make up for that difference.

[There are several ways to share the object database between multiple
working dirs in git; e.g.  "git clone --reference"]

-Miles

-- 
Consult, v.i. To seek another's disapproval of a course already decided on.

Re: MAINTAINERS file

[Thien-Thi Nguyen]

() Jason Earl <jearl@xmission.com>
() Tue, 04 Mar 2008 17:17:56 -0700

   My original plan was to pipe up on the lists *after* I had something
   that I knew worked, but I'm pretty close, and I thought I might save
   someone the trouble of duplicating my efforts.

What does "pretty close" mean, precisely?  (What problems remain?)

thi

Re: MAINTAINERS file

[Jason Earl]

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

> () Jason Earl <jearl@xmission.com>
> () Tue, 04 Mar 2008 17:17:56 -0700
>
>    My original plan was to pipe up on the lists *after* I had something
>    that I knew worked, but I'm pretty close, and I thought I might save
>    someone the trouble of duplicating my efforts.
>
> What does "pretty close" mean, precisely?  (What problems remain?)

In this particular case "pretty close" means that I am not quite done
importing the source code.  As of right now I have imported 92717 of
97275 patchsets.  Importing via cvsps-import is brutally slow.

Once everything is imported I would need to verify that everything
worked.  I tried using cvsps-import previously and had a problem using
the repository after the import was completed.  The repository was
missing a few changesets.  It turns out that the problems were primarily
caused by me, but they did cost me a week (while I waited for the import
to finish), plus several days troubleshooting.  I then used my spare
time in the next several weeks playing around with some of the other
available methods for migrating from CVS (or git) to bzr.

I didn't really want to come forward until I had something that worked.
It still is very possible that my current cvsps-import will fail.  I
really debated speaking up about my experiments, because for the most
part they have shown that bzr's import tools aren't quite up to the task
of converting Emacs.  I have, however, made enough progress that I would
almost certainly would be helpful to anyone that was interested in
experimenting with bzr for themselves.  Plus, I *have* been meaning to
find a way to help with Emacs development :).

Jason

Re: MAINTAINERS file

[Thien-Thi Nguyen]

() Jason Earl <jearl@xmission.com>
() Wed, 05 Mar 2008 16:07:38 -0700

   In this particular case "pretty close" means
   [importing was in progress].

Thanks for the clarification.
   
   [Importing is slow.]  I then used my spare time in the next
   several weeks playing around with some of the other available
   methods for migrating from CVS (or git) to bzr.

This is something all programmers migrating to bzr from CVS (or
git) will have to do.  So, ...

   [...] I really debated speaking up about my experiments,
   because for the most part they have shown that bzr's import
   tools aren't quite up to the task of converting Emacs.  I have,
   however, made enough progress that I would almost certainly
   would be helpful to anyone that was interested in experimenting
   with bzr for themselves.

..., i suggest you set up a public bzr repo of that tool, w/ a
nice fat warning in the README.  This will help people to: play w/
bzr directly; use it to flush out problems w/ the import process;
and use it to flush out problems w/ Emacs' bzr (and other dVCS)
support.  Two (plus) birds w/ one stone.

(Of course, there is the risk that one of the birds to be struck
will be people's patience w/ multi-level breakage.  That flighty
thing, yet hard of wing... :--)

thi

Re: MAINTAINERS file

[Jason Earl]

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

> () Jason Earl <jearl@xmission.com>
> () Wed, 05 Mar 2008 16:07:38 -0700
>
>    In this particular case "pretty close" means
>    [importing was in progress].
>
> Thanks for the clarification.

My pleasure.

>    [Importing is slow.]  I then used my spare time in the next
>    several weeks playing around with some of the other available
>    methods for migrating from CVS (or git) to bzr.
>
> This is something all programmers migrating to bzr from CVS (or
> git) will have to do.  So, ...

Yes, but they only have to do it once per project, and most projects
have far less to convert than Emacs.

>    [...] I really debated speaking up about my experiments,
>    because for the most part they have shown that bzr's import
>    tools aren't quite up to the task of converting Emacs.  I have,
>    however, made enough progress that I would almost certainly
>    would be helpful to anyone that was interested in experimenting
>    with bzr for themselves.
>
> ..., i suggest you set up a public bzr repo of that tool, w/ a nice
> fat warning in the README.  This will help people to: play w/ bzr
> directly; use it to flush out problems w/ the import process; and use
> it to flush out problems w/ Emacs' bzr (and other dVCS) support.  Two
> (plus) birds w/ one stone.

That's the idea.  Once the initial conversion is complete keeping the
bzr repo in sync with the official Emacs CVS repo should be fairly
straightforward.

> (Of course, there is the risk that one of the birds to be struck will
> be people's patience w/ multi-level breakage.  That flighty thing, yet
> hard of wing... :--)

I happen to like bzr.  I've played around with all of the major (and
most of the minor) revision control systems and I believe that bzr
strikes a nice balance between usability and functionality.  It is easy
to deploy (no smart server required), it's commands are familiar to
people that have used cvs and it supports a wide variety of workflows
including a CVS/subversion style workflow with "bound" branches.  It
installs easily anywhere that Python 2.4 runs, and it has a large and
talented group of hackers working on it.  I would like to see Emacs move
in that direction.

On the other hand, I don't think that Emacs could go wrong with either
git (assuming that a workable Windows client could be found) or
Mercurial, and I have already successfully created a Mercurial Emacs
repository from the existing git repository.  To be honest, as much as I
like bzr, Mercurial is hard to beat.

Jason

Re: MAINTAINERS file

[Thien-Thi Nguyen]

() Jason Earl <jearl@xmission.com>
() Thu, 06 Mar 2008 12:09:29 -0700

   Yes, but they only have to do it once per project, and most
   projects have far less to convert than Emacs.

"Only once" is an ideal case.  You have to budget for pebkac
and other delightful realities.  On the positive side, many
invocations may be indicative of lots of user experimentation.
Anyway, that's enough spew from me; i look forward to trying
out the program.

thi

Re: MAINTAINERS file

[Juanma Barranquero]

On Tue, Mar 4, 2008 at 1:56 AM, Richard Stallman <rms@gnu.org> wrote:

> We should use Bzr because that is becoming a GNU package.
>  GNU packages should show loyalty to each other when possible,
>  and in this case it is possible.

Yes, I can easily imagine the faces of any vi-loving Bazaar developer
if we asked them to drop it and use Emacs...

             Juanma

Re: MAINTAINERS file

[Thien-Thi Nguyen]

() "Juanma Barranquero" <lekktu@gmail.com>
() Tue, 4 Mar 2008 13:56:47 +0100

   Yes, I can easily imagine the faces of any vi-loving Bazaar
   developer if we asked them to drop it and use Emacs...

Hey, i love vi (the same way i love sunsets: from afar, w/ a nice
cool beer on a hot day, hacking on Emacs in Emacs, head toasted
gently by the trees tickling the brain :-) ...

But, i don't use bzr.  I hope that 1/ the git<->bzr gateway grows
fully-functional quickly; 2/ someone starts a GPLv3+ (able to be
subsequently adopted by GNU) project that reads/writes git repo
format.  Hey look, we already have sha1.el (though its Commentary
sez: "Rewrite from scratch", hmm).

thi

Re: MAINTAINERS file

[Jeremy Maitin-Shepard]

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

> () "Juanma Barranquero" <lekktu@gmail.com>
> () Tue, 4 Mar 2008 13:56:47 +0100

>    Yes, I can easily imagine the faces of any vi-loving Bazaar
>    developer if we asked them to drop it and use Emacs...

> Hey, i love vi (the same way i love sunsets: from afar, w/ a nice
> cool beer on a hot day, hacking on Emacs in Emacs, head toasted
> gently by the trees tickling the brain :-) ...

> But, i don't use bzr.  I hope that 1/ the git<->bzr gateway grows
> fully-functional quickly; 2/ someone starts a GPLv3+ (able to be
> subsequently adopted by GNU) project that reads/writes git repo
> format.

"Reads/writes git repo format" essentially means a compatible
reimplementation of git.  Reimplementing git solely to be able to
license it under GPLv3 instead of GPLv2 is one of the biggest wastes of
time I've ever heard of.

More seriously, I think the goal of the GNU project should be to promote
free software.  Showing "loyalty" to another GNU project by using it in
favor of an alternative that is equally free and may be technically
superior does nothing to promote free software.  (In fact, to the extent
that using an inferior tool may interfere with Emacs development, the
Emacs project, and consequently free software as a whole, is harmed.)
Favoring projects that have the "GNU" label suggests a real motivation
of merely promoting the "GNU" name.

You may argue that promoting the "GNU" name is important for promoting
free software, but I don't buy that.  When it was first founded, the FSF
may have been the only "producer" of free software, but that is
obviously no longer true, and this fact reflects the now widespread
adoption and popularity of free software.  Sure, you may be sour that
the name "Linux" is far more widely known and used than the name "GNU",
and it is legitimate to be slightly upset that "Linus Torvalds" may be a
name slightly more widely known than "Richard Stallman" (though I'm not
even sure how true that is), but given that most of the people that use
the name "Linux" to refer to what is actually a system running the Linux
kernel (probably compiled using GCC) plus the usual glibc, coreutils,
findutils, etc., X11, other stuff have no idea what "Linux" technically
actually means (and certainly are just confused by names like BSD or
Hurd), you cannot expect that merely having more people blindly use the
name "GNU" will actually increase their understanding of the idea of
free software.  Instead, it is more useful to actually promote the idea
of free software directly.

I think the most significant barrier to greater appreciation for the
idea of free software is the fact that it is very hard for
non-programmers to understand or appreciate the idea of free software,
and the vast majority of computer users are non-programmers.

> Hey look, we already have sha1.el (though its Commentary
> sez: "Rewrite from scratch", hmm).

> thi

-- 
Jeremy Maitin-Shepard

Re: MAINTAINERS file

[Eli Zaretskii]

> From: Jeremy Maitin-Shepard <jeremy@jeremyms.com>
> Date: Tue, 04 Mar 2008 13:41:24 -0500
> Cc: Juanma Barranquero <lekktu@gmail.com>, rms@gnu.org,
> 	Emacs Devel <emacs-devel@gnu.org>
> 
> Thien-Thi Nguyen <ttn@gnuvola.org> writes:
> 
> > () "Juanma Barranquero" <lekktu@gmail.com>
> > () Tue, 4 Mar 2008 13:56:47 +0100
> 
> >    Yes, I can easily imagine the faces of any vi-loving Bazaar
> >    developer if we asked them to drop it and use Emacs...
> 
> > Hey, i love vi (the same way i love sunsets: from afar, w/ a nice
> > cool beer on a hot day, hacking on Emacs in Emacs, head toasted
> > gently by the trees tickling the brain :-) ...
> 
> > But, i don't use bzr.  I hope that 1/ the git<->bzr gateway grows
> > fully-functional quickly; 2/ someone starts a GPLv3+ (able to be
> > subsequently adopted by GNU) project that reads/writes git repo
> > format.
> 
> "Reads/writes git repo format" essentially means a compatible
> reimplementation of git.  Reimplementing git solely to be able to
> license it under GPLv3 instead of GPLv2 is one of the biggest wastes of
> time I've ever heard of.
> 
> Showing "loyalty" to another GNU project by using it in
> favor of an alternative that is equally free and may be technically
> superior does nothing to promote free software.

It promotes the GNU Project, which is one of the main players in the
field of free software, because the GNU Project is, among other
things, a grabbag of lots of free software.

> (In fact, to the extent
> that using an inferior tool may interfere with Emacs development, the
> Emacs project, and consequently free software as a whole, is harmed.)

I'm sure you don't want to claim that bzr is "inferior".  (If you do,
please provide some evidence.)  No one here will want to use an
inferior tool.  The issue is, all things being approximately equal,
which tool to choose.

> Favoring projects that have the "GNU" label suggests a real motivation
> of merely promoting the "GNU" name.
> 
> You may argue that promoting the "GNU" name is important for promoting
> free software, but I don't buy that.

This is a misunderstanding: we are not talking about names or labels.
Being a GNU package means much more than just a word in a name.

Re: MAINTAINERS file

[Jeremy Maitin-Shepard]

Eli Zaretskii <eliz@gnu.org> writes:

[snip]

>> (In fact, to the extent
>> that using an inferior tool may interfere with Emacs development, the
>> Emacs project, and consequently free software as a whole, is harmed.)

> I'm sure you don't want to claim that bzr is "inferior".  (If you do,
> please provide some evidence.)  No one here will want to use an
> inferior tool.  The issue is, all things being approximately equal,
> which tool to choose.

I'm not claiming that bzr is necessarily inferior; I don't know enough
about bzr to be sure.  What I'm claiming is that it _might_ be inferior,
and it seems the decision to use it was based on largely on it being
"GNU" and seeming to be at least "decent".  In particular, it seems that
the decision to use it was not based on any actual experience in using
bzr or any alternatives.

One thing that git has going for it over the alternatives is a very
large and active developer base.

>> Favoring projects that have the "GNU" label suggests a real motivation
>> of merely promoting the "GNU" name.
>> 
>> You may argue that promoting the "GNU" name is important for promoting
>> free software, but I don't buy that.

> This is a misunderstanding: we are not talking about names or labels.
> Being a GNU package means much more than just a word in a name.

Sure, being a GNU package means that the package is consistent with free
software ideology, but it is important to realize that _not_ being a GNU
package does not mean that it is inconsistent with free software
ideology.  In particular, you can't claim that using bzr will somehow
help the free software movement more than using Git or Mercurial will.

-- 
Jeremy Maitin-Shepard

Re: MAINTAINERS file

[Stefan Monnier]

DaRCS, Git, Bazaar, Monotone, Mercurial, Svn, and a bunch of others all
have something going for them.  Even CVS has a lot of things going for it.

I don't think Svn is a good option a this stage.
As much as I like Haskell and as much as I like some of the ideas in
DaRCS, I do not think it's a good choice right now because of some
serious scalability problems that can show up in corner cases.

Of the remaining 4 I think they'd all fit the bill just fine, each with
its own strengths and weaknesses.  So the choice among those 4 is mostly
arbitrary.

Making the choice based on ideological reasons makes a lot of sense in
a context where the difference between Open Source and Free Software is
stark yet purely ideological.


        Stefan

Re: MAINTAINERS file

[Eli Zaretskii]

> From: Jeremy Maitin-Shepard <jeremy@jeremyms.com>
> Cc: emacs-devel@gnu.org, Juanma Barranquero <lekktu@gmail.com>, rms@gnu.org
> Date: Tue, 04 Mar 2008 15:28:04 -0500
> 
> I'm not claiming that bzr is necessarily inferior; I don't know enough
> about bzr to be sure.  What I'm claiming is that it _might_ be inferior,
> and it seems the decision to use it was based on largely on it being
> In particular, it seems that the decision to use it was not based on
> any actual experience in using bzr or any alternatives.

Well, how about reading the discussions about this in
the-not-so-distant past here.  Then you can draw your conclusions.

Re: MAINTAINERS file

[Juanma Barranquero]

On Wed, Mar 5, 2008 at 4:43 PM, Eli Zaretskii <eliz@gnu.org> wrote:

>  Well, how about reading the discussions about this in
>  the-not-so-distant past here.  Then you can draw your conclusions.

I've read several discussions here about dVCS in the not-so-distant
past, for several values of "distant". I don't think technical
conclusions can be drawn from them. No one has offered hard data or
done an unbiased comparison. The only one to try, that I remember, is
Eric, and he went missing just after bringing up the issue (to be
fair: he has explained why).

So, if we're going to use Bazaar for political reasons, so be it. But
statements of opinion like this one from Stefan (nothing special about
it, it's just the one I had closer at hand)

"Of the remaining 4 I think they'd all fit the bill just fine, each
with its own strengths and weaknesses.  So the choice among those 4 is
mostly arbitrary."

are hardly compelling.

What I'm trying to say is: I won't discuss which dVCS we choose
(unless it makes Windows development a PITA). But I agree with Jeremy
Maitin-Shepard that the cause of free software is strengthened by us
selecting among the free alternatives the one that best serves our
technical, not political, needs.

             Juanma

Re: MAINTAINERS file

[Richard Stallman]

    What I'm trying to say is: I won't discuss which dVCS we choose
    (unless it makes Windows development a PITA). But I agree with Jeremy
    Maitin-Shepard that the cause of free software is strengthened by us
    selecting among the free alternatives the one that best serves our
    technical, not political, needs.

That is completely backwards.  The free software movement is a
political cause, not a technical one.  "Choose based on technical
criteria first of all" is the opposite of what we say.

There are many reasons why GNU packages should support other GNU
packages.

The GNU Project is not just a collection of software packages.  Its
intended result is a coherent operating system.  It is particularly
important therefore that GNU packages should work well with other GNU
packages.  For instance, we would like Emacs to work well with git or
mercurial, but we especially want it to work well with Bzr.

The maintainers of one GNU package should use other GNU packages so
they will notice whether the packages work well together, and make
them work well together.

We also promote use of other GNU packages in this way.
Other people don't necessarily see which editor you use,
but they all see what dVCS you use.

Re: MAINTAINERS file

[Juanma Barranquero]

On Fri, Mar 7, 2008 at 4:37 AM, Richard Stallman <rms@gnu.org> wrote:

>  That is completely backwards.  The free software movement is a
>  political cause, not a technical one.  "Choose based on technical
>  criteria first of all" is the opposite of what we say.

That's twisting a bit what I said, I think. I specifically said
"selecting among the free alternatives", so it is clear that politics
plays an important part.

>  There are many reasons why GNU packages should support other GNU
>  packages.

Yes. But then, you're equating "support" with "use with preference to
other free alternatives", and I don't think that follows necessarily.

>  The GNU Project is not just a collection of software packages.  Its
>  intended result is a coherent operating system.  It is particularly
>  important therefore that GNU packages should work well with other GNU
>  packages.

By that reasoning, we all should try using GNU/Hurd, shouldn't we?

>  The maintainers of one GNU package should use other GNU packages so
>  they will notice whether the packages work well together, and make
>  them work well together.

Perhaps. But if git were used by 90% of users, and Bazaar by 5% (I'm
making up the numbers, of course), time spent in making Emacs work
well with git would be better spent, from a free software perspective.

>  Other people don't necessarily see which editor you use,
>  but they all see what dVCS you use.

That would be more convincing if every GNU package except by Emacs
were using Bazaar. Is that so?

             Juanma

Re: MAINTAINERS file

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On Fri, Mar 7, 2008 at 4:37 AM, Richard Stallman <rms@gnu.org> wrote:
>
>>  Other people don't necessarily see which editor you use, but they
>>  all see what dVCS you use.
>
> That would be more convincing if every GNU package except by Emacs
> were using Bazaar. Is that so?

Emacs is not particularly known for only going well-trodden paths.  In
more than one way it has been a front-runner for Free Software and the
policies (I don't think we have much other software that requires the
GNU manifesto in its manual).

So the right question is not "do the other GNU packages do that?" but
rather "would we like GNU packages to do that?".  And then Emacs is at
least as good a start as any.

Incidentally, the answer for me to this one is "no", but it is still a
valid question.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: MAINTAINERS file

[Juanma Barranquero]

On Fri, Mar 7, 2008 at 10:20 AM, David Kastrup <dak@gnu.org> wrote:

>  Emacs is not particularly known for only going well-trodden paths.  In
>  more than one way it has been a front-runner for Free Software and the
>  policies

I know. But Richard was not saying that we should use Bazaar with
Emacs because Emacs is one of GNU flagship projects, but that all GNU
projects *should use* Bazaar.

>  So the right question is not "do the other GNU packages do that?" but
>  rather "would we like GNU packages to do that?".  And then Emacs is at
>  least as good a start as any.
>
>  Incidentally, the answer for me to this one is "no", but it is still a
>  valid question.

IIUC, you're saying "no" to "would we like GNU packages to do that?"
(ie, using Bazaar). I'm agnostic; I'm just not comfortable with the
idea of not taking into account reliability, user interface,
scalability, performance, etc., and blindly assuming that all current
dVCS are more-or-less equivalent. git is quite fast; mercurial has a
nice interface, etc. Using one or another does definitely not offer
the same experience, even if the functionality is very similar.

             Juanma

Re: MAINTAINERS file

[Thomas Lord]

Juanma Barranquero wrote:
> IIUC, you're saying "no" to "would we like GNU packages to do that?"
> (ie, using Bazaar). I'm agnostic; I'm just not comfortable with the
> idea of not taking into account reliability, user interface,
> scalability, performance, etc., and blindly assuming that all current
> dVCS are more-or-less equivalent. git is quite fast; mercurial has a
> nice interface, etc. Using one or another does definitely not offer
> the same experience, even if the functionality is very similar.
>   


Probably so but any group of smart people could easily spend
a year arguing about it.   Not even a year arguing about which system
is best but a year arguing just about what "best" means in this context.

Over-optimizing a choice like that can be a *huge* resource
suck and projects and groups fail all the time because of falling
into such traps.

RMS' "style" of running GNU, at least as I've seen it over many
years, is to try to avoid getting hung up that way.   Instead:  just
pick (or build) a list of free software programs that, at least if you
just look at their one-line summaries, should add up to a Complete
GNU System.    Now you are mostly "done".   The next step is
to observe this funky heap of programs and ask "Why does this collection
fail to function well as a complete system?" and then fix those
problems.   Then you're done. 

So, if it seems arbitrary that RMS dubs program X a GNU program
and then says "the Emacs project should use X" well, it probably
is arbitrary -- but the arbitrariness is part of a larger, pretty sane
strategy.   X made the list.   Hope that it's "good enough" to polish
into a component of the complete system.   Worst case is to eventually
back-track and pick an alternative X'.   (GCC, for example, started
out just that way.   So did the current Emacs.    GCC started from
a compiler written in pascal that turned out to not be "good enough"
and Emacs from another Emacs that didn't have a true lisp in it.
Bad choices of X happen but, they tend to get ironed out well so
when it comes time to pick an X, there's no great reason to spend
too much time deliberating over it.


-t

(Maybe, though, it is about time for a new task list and "vision
sketch" of a complete GNU.   For example, an effort could be made
to assemble a candidate FSF/GNU distribution with the expectation
that the effort will fail, but will yield a list of what work remains to
be done.)

Re: MAINTAINERS file

[Juanma Barranquero]

On Fri, Mar 7, 2008 at 7:47 PM, Thomas Lord <lord@emf.net> wrote:

>  Probably so but any group of smart people could easily spend
>  a year arguing about it.   Not even a year arguing about which system
>  is best but a year arguing just about what "best" means in this context.
>
>  Over-optimizing a choice like that can be a *huge* resource
>  suck and projects and groups fail all the time because of falling
>  into such traps.

Perhaps so, but on the other hand, many a project, some of them quite
big, have been able to select a dVCS without spending a year arguing
or failing into any trap.

>  Bad choices of X happen but, they tend to get ironed out well so
>  when it comes time to pick an X, there's no great reason to spend
>  too much time deliberating over it.

There's a difference between "not [...] to spend too much time" and
not spending time at all.

>  (Maybe, though, it is about time for a new task list and "vision
>  sketch" of a complete GNU.   For example, an effort could be made
>  to assemble a candidate FSF/GNU distribution with the expectation
>  that the effort will fail, but will yield a list of what work remains to
>  be done.)

That would be interesting.

             Juanma

Re: MAINTAINERS file

[Thomas Lord]

[-- Attachment #1: Type: text/plain, Size: 2055 bytes --]

Juanma Barranquero wrote:
> Perhaps so, but on the other hand, many a project, some of them quite
> big, have been able to select a dVCS without spending a year arguing
> or failing into any trap.
>   

Sure, and, mostly the same way:  the boss(es) just pick one,
somewhat arbitrarily but perhaps with some intuition about
what will work out.


>>  Bad choices of X happen but, they tend to get ironed out well so
>>  when it comes time to pick an X, there's no great reason to spend
>>  too much time deliberating over it.
>>     
>
> There's a difference between "not [...] to spend too much time" and
> not spending time at all.
>
>   

Sure.  I'm not trying to argue with you -- just interpret for you and
maybe help you feel more comfortable with the decision.

There's some arbitrary amount of time to think about it.  Then some
best-guess decision.    GNU tends to work by, when such infathomable
problems arise, let RMS roll the dice, so to speak: he times and makes
the "impossible" choices.   In this case, ESR, bless his heart, seems to 
have
prompted quite a few list members to go back and refresh their
perspective on dvcs and spout some observations and opinions.   So,
RMS got a fair amount of input.   No one "argument in favor of system
X" has obviously prevailed or obviously could prevail but the decision
wasn't taken in a vacuum.

The harsh version of the interpretation might be "Well, GNU is
RMS' project so it's his call.  Like or lump it."   I'm just trying to point
out that that's not a crazy policy because, in calling for a different
approach to the decision, you're suggesting a (pretty radical) change
in policy.

>>  (Maybe, though, it is about time for a new task list and "vision
>>  sketch" of a complete GNU.   For example, an effort could be made
>>  to assemble a candidate FSF/GNU distribution with the expectation
>>  that the effort will fail, but will yield a list of what work remains to
>>  be done.)
>>     
>
> That would be interesting.
>
>   

Thanks.  I think so, too.

-t


>              Juanma
>
>   


[-- Attachment #2: Type: text/html, Size: 3058 bytes --]

Re: MAINTAINERS file

[Juanma Barranquero]

On Sat, Mar 8, 2008 at 3:27 AM, Thomas Lord <lord@emf.net> wrote:

>  Sure, and, mostly the same way:  the boss(es) just pick one,
>  somewhat arbitrarily but perhaps with some intuition about
>  what will work out.

Some have done just that, and some others did have discussions. I'm
just pointing out that stopping to evaluate the alternatives is not
dangerous per se.

> In this case, ESR, bless his heart, seems to
> have
>  prompted quite a few list members to go back and refresh their
>  perspective on dvcs and spout some observations and opinions.   So,
>  RMS got a fair amount of input.

I don't think so. Very few people has experience with several dVCS;
most discussion (at least, in this list) has not gone over the level
of "this is the dVCS I'm comfortable with".

> I'm just trying to
> point
>  out that that's not a crazy policy because, in calling for a different
>  approach to the decision, you're suggesting a (pretty radical) change
>  in policy.

I don't think Richard's policies are crazy; I respect him and his
accomplishments. But I'm don't think either that what I'm suggesting
is a radical change in policy, unless "stop and look at the
alternatives" is considered radical.

             Juanma

Re: MAINTAINERS file

[Thomas Lord]

So, one or both of us should probably get rightly flamed soon
for being too off-topic or not trimming CC's or something
but I'll risk at least one more round:

Juanma Barranquero wrote:
> I don't think Richard's policies are crazy; I respect him and his
> accomplishments. But I'm don't think either that what I'm suggesting
> is a radical change in policy, unless "stop and look at the
> alternatives" is considered radical.
>
>   


As a kibbitz I agree with you.   I'd even put it more strongly.
And this will also illustrate how I basically agree with ESR's
sentiment about version control even if I disagree with many
details of where he took it:

The GNU project as amassed an enormous treasure of software
tools:  all of the programs dubbed "GNU".   Legal ownership
of copyrights is all over the map but in some tangible way you
could say that "GNU just *has* all of these software 'assets'."

Most of those tools, by the way, are moving targets: development
continues on them with or without a GNU project per-se.  So,
this is a very "virtual" collection of software that comprises GNU.
It's a big bag of projects-that-share-mutual-good-will as much as
its any particular big bag of source code bits.

GNU has historically been good at growing its treasure of software
tools, but historically very poor at organize those into larger systems.
Other people, other groups, with agendas that are different from the
the free software movement's have taken over that function:  Parties
outside of GNU organize collections like this into "complete systems"
but GNU itself has failed to do so.

Well, it doesn't take "rocket science" to organize lots of tool
projects into a "complete system" project but it does take a lot of
coordination, record keeping, archival, etc.   There's a huge
*information management problem* to solve and that problem is about
organizing the output of all of the individual, moving-target,
software-tools free software source code projects.

Another way to say it is that, to really start thinking about
building a complete system, GNU has to find a way to turn the
list of GNU programs into a kind of living archive of those source
code resources.   With things nicely organized, then a lot of the tedious
work of assembling complete distros can begin to be systematized.

The alternative to that kind of "bureaucratization" looks like
Debian: throw people at the problem.    Debian works on the
integration problem by doubling up, roughly, on the number of
project maintainers so that every project has a shadow maintainer
in Debian who does the pavement-hitting foot work of gathering
up source and moving into the Debian collection.

The Debian-like alternative is *incredibly expensive* if we are
counting up *labor*.   It is (relative to most projects) a *huge*
effort.   There has to be a more efficient approach.

GNU *could* contemplate the dvcs problem from *that* angle:
trying to find ways to encourage the individual projects to make
tool choices that make complete systems much less expensive
to assemble.   That, in my opinion, would be a good investment
strategy (though a challenging mess of tactical problems).

A dcvs choice is important from that very broad perspective:
thinking about it as a choice that governs the "inventory system"
for the GNU project's source code.

It's hard, though, to make  that case.   There's not a lot of point
to making up strategies for organizing all the source of a complete
distro unless it's realistic that there will be resources to follow up
on that strategizing.   There seem not to be such resources so, there's
a sharp limit on the value of strategic thinking for GNU.

-t

Re: MAINTAINERS file

[Juanma Barranquero]

On Sat, Mar 8, 2008 at 4:06 AM, Thomas Lord <lord@emf.net> wrote:

> So, one or both of us should probably get rightly flamed soon
>  for being too off-topic or not trimming CC's or something
>  but I'll risk at least one more round:

Your analysis of the GNU project's failure to "organize software tools
into larger systems" (to quote your words) is very interesting. But
now we're straying too far from the current topic. I'll stop here. I
think we've discussed enough; let's avoid the flames ;-)

Many thanks for your comments.

             Juanma

Re: MAINTAINERS file

[Richard Stallman]

    (Maybe, though, it is about time for a new task list and "vision
    sketch" of a complete GNU.

This could be a useful project (but let's make a separate list to
discuss it).

Re: MAINTAINERS file

[Davi Leal]

Richard Stallman wrote:
>     (Maybe, though, it is about time for a new task list and "vision
>     sketch" of a complete GNU.
>
> This could be a useful project (but let's make a separate list to
> discuss it).

I am interested in joining such new list to expose what everybody already 
knows about Savannah and Bazaar integration improvement, etc., etc.


What is the name of such new list,  integration@gnu.org ?

Re: MAINTAINERS file

[Richard Stallman]

    >  Emacs is not particularly known for only going well-trodden paths.  In
    >  more than one way it has been a front-runner for Free Software and the
    >  policies

    I know. But Richard was not saying that we should use Bazaar with
    Emacs because Emacs is one of GNU flagship projects,

I didn't say that, but now that people mention it, it is another good
reason.

							 but that all GNU
    projects *should use* Bazaar.

They should do so when it makes sense.  I won't insist that every GNU
package use a VCS, or that every GNU package use a dVCS.  But if it
uses a dVCS, it may as well be Bazaar.

Re: MAINTAINERS file

[Robert J. Chassell]

   ... I specifically said "selecting among the free alternatives" ...

In English, the word `free' has two meanings, `no charge' or `gratis'
and `freedom' or `libre'.  Thus there is a `free market' meaning
people may enter legally, but there may be a charge for products, and
`free beer' meaning gratis beer.  (Beer sold in a free market would be
`free market beer'.)

Some software is gratis but is restricted.  In addition, there is a
methodology, called `open software development', which confuses
matters.

The GNU Project is concerned with freedom, which is to say, freedom,
free markets, and the free press.  It is not concerned with cost.

As it happens, software is a high initial, low incremental cost
product, like law, armies, or reading: an initial program costs a fair
amount since it must be written, but a copied program costs little.
So the technology is one in which in a competitive market, a `free
market', the price of software drops.  Indeed, the price when
unrestricted, for software for which you have freedom is often
considered gratis by the end user.

That is why the opponents of a market with freedom, the opponents of
`free markets', seek governmental enforcements of restrictions on
sales.  They are against the freedom of others to pay the price that
competition would ensure.  Moreover, they like to call those
restrictions `property', as if the restrictions applied to a ship
rather than to software.

--
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: MAINTAINERS file

[Juanma Barranquero]

On Fri, Mar 7, 2008 at 5:39 PM, Robert J. Chassell <bob@rattlesnake.com> wrote:

>  In English, the word `free' has two meanings, `no charge' or `gratis'
>  and `freedom' or `libre'.

Oh, gosh. Really?

>  That is why the opponents of a market with freedom, the opponents of
>  `free markets', seek governmental enforcements of restrictions on
>  sales.  They are against the freedom of others to pay the price that
>  competition would ensure.

Thanks the gods for some non-free markets... but that's a discussion
for another day.

For now, I think you can safely assume I know all that and was
referring to libre dVCS, not gratis dVCS.

             Juanma

Re: MAINTAINERS file

[Richard Stallman]

    >  The GNU Project is not just a collection of software packages.  Its
    >  intended result is a coherent operating system.  It is particularly
    >  important therefore that GNU packages should work well with other GNU
    >  packages.

    By that reasoning, we all should try using GNU/Hurd, shouldn't we?

If the Hurd were ready for general use, then I would ask everyone
to try it, for that reason.  But it isn't.

That has nothing to do with the case at hand.  You're exaggerating
what I said, then criticizing your exaggeration.  That is just a straw
man.  It is not useful.

    >  The maintainers of one GNU package should use other GNU packages so
    >  they will notice whether the packages work well together, and make
    >  them work well together.

    Perhaps. But if git were used by 90% of users, and Bazaar by 5%

So what?  The decision I've made is for the real situation.

However, but your hypothetical world is relevant in one way: we want
to avoid letting it happen.  By making Emacs support Bzr as well as
possible, and by using Bzr and saying so, we will encourage other
projects to use Bzr, and thus give it a better chance not to end up
with 5%.

    >  Other people don't necessarily see which editor you use,
    >  but they all see what dVCS you use.

    That would be more convincing if every GNU package except by Emacs
    were using Bazaar. Is that so?

You're the one trying to convince me.  I'm just explaining.

You argument seems to say that the GNU Project should never
establish a new convention and ask projects to follow it,
because no package should ever be asked first.


We already know the most important thing about what we will find from
a careful study of git, mercurial and Bzr.  We will find that each has
its advantages and disadvantages -- but none of them conclusive.  Each
will be preferred by some people, but any one of them would work out
well enough.

The best thing to do is to choose the one that is the GNU package is
easier, and get the decision over with.

Re: MAINTAINERS file

[Juanma Barranquero]

On Sun, Mar 9, 2008 at 3:17 AM, Richard Stallman <rms@gnu.org> wrote:

>  If the Hurd were ready for general use, then I would ask everyone
>  to try it, for that reason.

So technical reasons are relevant there...

>  That has nothing to do with the case at hand.  You're exaggerating
>  what I said, then criticizing your exaggeration.  That is just a straw
>  man.  It is not useful.

You misread what I said as meaning that politics were unimportant,
then criticized that.

>  So what?  The decision I've made is for the real situation.

What is the real situation? Do we have data about the number of users
of Bazaar vs. git or mercurial?

>  You're the one trying to convince me.  I'm just explaining.

No, I'm not really trying to convince you. I'm explaining why your
decision, in this particular case, seems to me unwise and arbitrary. I
already said "if we're going to use Bazaar for political reasons, so
be it".

>  You argument seems to say that the GNU Project should never
>  establish a new convention and ask projects to follow it,
>  because no package should ever be asked first.

I thought you were opposed to straw man arguments... That's
overgeneralizing what I said to the extreme.

>  We already know the most important thing about what we will find from
>  a careful study of git, mercurial and Bzr.  We will find that each has
>  its advantages and disadvantages -- but none of them conclusive.  Each
>  will be preferred by some people, but any one of them would work out
>  well enough.

We know we will find that, when there's been no unbiased comparison.
Curious. The only way to know that with such certainty is with the a
priori supposition that it will be so.

>  The best thing to do is to choose the one that is the GNU package is
>  easier, and get the decision over with.

That's what you've saying all along.

             Juanma

Re: MAINTAINERS file

[Thien-Thi Nguyen]

() "Juanma Barranquero" <lekktu@gmail.com>
() Mon, 10 Mar 2008 00:34:13 +0100

   What is the real situation? Do we have data about the
   number of users of Bazaar vs. git or mercurial?

The real situation is that numbers don't matter, except in a popularity
contest.  What matters (technically) is that moving from central repo to
distributed repo pushes interop between these systems to the forefront.

  JRHACKER <-> PREFERRED-VCS <-> PROJECT-VCS <-> WORLD (PROJECT)

What matters (politically) is that PROJECT-VCS is compatible w/ PROJECT,
and that PREFERRED-VCS is compatible w/ JRHACKER.

Interop is a burden but not a fruitless one.  Likewise, understanding
different people w/ their different persepectives.  (Note: I spew
generally here, w/o intention of speaking on anyone's abilities or
intentions.)

thi

Re: MAINTAINERS file

[Juanma Barranquero]

On Mon, Mar 10, 2008 at 9:15 AM, Thien-Thi Nguyen <ttn@gnuvola.org> wrote:

>  The real situation is that numbers don't matter, except in a popularity contest.

I find difficult to agree with the rest, when I don't agree with the
premise. It is way too general (yes, I know you're "spewing
generality") to be meaningful.

             Juanma

Re: MAINTAINERS file

[Thien-Thi Nguyen]

() "Juanma Barranquero" <lekktu@gmail.com>
() Mon, 10 Mar 2008 10:11:08 +0100

   I find difficult to agree with the rest, when I don't agree
   with the premise.  It is way too general (yes, I know you're
   "spewing generality") to be meaningful.

No worries, agreement is optional.

thi

Re: MAINTAINERS file

[Harsha]

[-- Attachment #1: Type: text/plain, Size: 1672 bytes --]

My (theoretical) ideal combination would be:

Savane plugged with Aegis, Aegis on HURD, HURD on Mach kernel.

I like the way aegis is (I mean architecture of aegis):

http://aegis.sourceforge.net/auug93.pdf
http://aegis.stepbuild.org/aegis-talk.pdf

Can this be considered as one of the alternatives in future?
when svn and other open-source vcs  etc.. expires :P

On Mon, Mar 10, 2008 at 1:45 PM, Thien-Thi Nguyen <ttn@gnuvola.org> wrote:

> () "Juanma Barranquero" <lekktu@gmail.com>
> () Mon, 10 Mar 2008 00:34:13 +0100
>
>   What is the real situation? Do we have data about the
>   number of users of Bazaar vs. git or mercurial?
>
> The real situation is that numbers don't matter, except in a popularity
> contest.  What matters (technically) is that moving from central repo to
> distributed repo pushes interop between these systems to the forefront.
>
>  JRHACKER <-> PREFERRED-VCS <-> PROJECT-VCS <-> WORLD (PROJECT)
>
> What matters (politically) is that PROJECT-VCS is compatible w/ PROJECT,
> and that PREFERRED-VCS is compatible w/ JRHACKER.
>
> Interop is a burden but not a fruitless one.  Likewise, understanding
> different people w/ their different persepectives.  (Note: I spew
> generally here, w/o intention of speaking on anyone's abilities or
> intentions.)
>
> thi
>
>
>


-- 
Cheers!!
Harsha Reddy

----------------------------

Of kind hearted people, (their) ear glows by (the knowledge) heard (by the
ear) & not by the ear ring (worn on ear), (their) hand glows by the donation
(given) by the hand & not by bracelet (worn on wrist), their body glows by
the selfless deeds done (by them to others) & not by (anointment with)
sandalwood (oil).

[-- Attachment #2: Type: text/html, Size: 2343 bytes --]

Re: MAINTAINERS file

[Thien-Thi Nguyen]

() Harsha <nharsha@gmail.com>
() Mon, 10 Mar 2008 17:20:37 +0530

   I like the way aegis is (I mean architecture of aegis):

That architecture incorporates testing in the change cycle,
which is nice, but sometimes (e.g., Emacs) there are no tests.

   Can this be considered as one of the alternatives in future?
   when svn and other open-source vcs  etc.. expires :P

For Emacs, if it can gateway to bzr, i don't see why not.
Probably nothing w/ serious users really expires.

thi

Re: MAINTAINERS file

[Walter Franzini]

[-- Attachment #1: Type: text/plain, Size: 712 bytes --]

Thien-Thi Nguyen <ttn-K5/C469f+89AfugRpC6u6w@public.gmane.org> writes:

> () Harsha <nharsha-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> () Mon, 10 Mar 2008 17:20:37 +0530
>
>    I like the way aegis is (I mean architecture of aegis):
>
> That architecture incorporates testing in the change cycle,
> which is nice, but sometimes (e.g., Emacs) there are no tests.

Under Aegis testing can be made optional on a per-project basis.

Just to clarify, I'm not trying to convince/convert anyone :-)

-- 
Walter Franzini
http://aegis.stepbuild.org/

PGP Public key ID: 1024D/CB3FEB43
Key fingerprint  : FA26 C33B CAFF 7848 EFEB  7327 96AA 2D57 CB3F EB43
Key server       : http://www.keyserver.net

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: MAINTAINERS file

[Gilaras Drakeson]

Hi all,

I have been lurking on this list, until now ...


      What is the real situation? Do we have data about the
      number of users of Bazaar vs. git or mercurial?

   The real situation is that numbers don't matter, except in a popularity
   contest.  

I strongly disagree here. In the choice of a distributed VCS, popularity
is an important factor not to be ignored. Technical issues are second to
that for practical purposes [*].

Having a single common distributed VCS among the large community of free
and open software developers can be very beneficial to the whole
community, in ways that were not possible until very recently.  Dividing
the community into bzr and git sects wastes this opportunity.

I can only hope that every relevant party puts the current (and
predicted future) usage numbers in their decision.

-- 
Gilaras Drakeson

[*] CVS and even RCS are in use today, which is not because of technical
    issues.

Re: MAINTAINERS file

[Richard Stallman]

    Having a single common distributed VCS among the large community of free
    and open software developers can be very beneficial to the whole
    community, in ways that were not possible until very recently.  Dividing
    the community into bzr and git sects wastes this opportunity.

We invite git users to switch to Bzr.

Re: MAINTAINERS file

[Richard Stallman]

    >  If the Hurd were ready for general use, then I would ask everyone
    >  to try it, for that reason.

    So technical reasons are relevant there...

Indeed they are.  My decision is based on the technical circumstances
and the overall goals of the GNU Project.

When there are several comparable, workable packages that do similar
jobs, we should use the one that is a GNU package.  That is the
situation here.

    >  So what?  The decision I've made is for the real situation.

    What is the real situation? Do we have data about the number of users
    of Bazaar vs. git or mercurial?

The real situation is that these programs are still developing, and
their competition is still developing too.  Whatever the current usage
figures are, they are liable to change.  So if, hypothetically,
Bzr is behind in the race at present, that is no reason to fail
to support it.

    >  You argument seems to say that the GNU Project should never
    >  establish a new convention and ask projects to follow it,
    >  because no package should ever be asked first.

    I thought you were opposed to straw man arguments... That's
    overgeneralizing what I said to the extreme.

That generalization comes from you.  It is the implicit premise of
what you said, so your argument rests on assuming it in full generality.

At least, that's how I understand what you said.  Here are your words:

    That would be more convincing if every GNU package except by Emacs
    were using Bazaar. Is that so?

They are rather vague and terse, so anyone trying to refute it has to
fill in what you left out.  I did my best.  If I did not fill it in
quite as you had in mind, you should have spoken more clearly.

    >  We already know the most important thing about what we will find from
    >  a careful study of git, mercurial and Bzr.  We will find that each has
    >  its advantages and disadvantages -- but none of them conclusive.  Each
    >  will be preferred by some people, but any one of them would work out
    >  well enough.

    We know we will find that, when there's been no unbiased comparison.

Yes, we know that much.  It is already clear that all three programs
are basically workable.

An "unbiased comparison" would show us detailed advantages of each.  I
don't know what they are, but I know they are not important enough to
override the GNU-level reason to choose the GNU package.  So I have
made the decision that way.

Re: MAINTAINERS file

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> The GNU Project is not just a collection of software packages.  Its
> intended result is a coherent operating system.  It is particularly
> important therefore that GNU packages should work well with other GNU
> packages.  For instance, we would like Emacs to work well with git or
> mercurial, but we especially want it to work well with Bzr.

git is the source code management system for Linux, and Linux is the
predominant kernel used (and endorsed for use) in GNU systems.

I don't even think that we use Bzr for Hurd, but I have not checked.

> The maintainers of one GNU package should use other GNU packages so
> they will notice whether the packages work well together, and make
> them work well together.

One has to get off the ground first.

> We also promote use of other GNU packages in this way.
> Other people don't necessarily see which editor you use,
> but they all see what dVCS you use.

Huh?  Of _course_ anybody looking at my computing will _immediately_ see
what editor I use.  Whereas the actual dVCS system comes only into play
between editing, and then VCS hides a lot of differences.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: MAINTAINERS file

[Richard Stallman]

    git is the source code management system for Linux, and Linux is the
    predominant kernel used (and endorsed for use) in GNU systems.

That is not particularly important, because Linux isn't a GNU package.
If it were a GNU package, I would write to its maintainers to suggest
using Bzr.

Re: MAINTAINERS file

[Johannes Weiner]

Hi,

David Kastrup <dak@gnu.org> writes:

>> We also promote use of other GNU packages in this way.
>> Other people don't necessarily see which editor you use,
>> but they all see what dVCS you use.
>
> Huh?  Of _course_ anybody looking at my computing will _immediately_ see
> what editor I use.  Whereas the actual dVCS system comes only into play
> between editing, and then VCS hides a lot of differences.

You see the dVCS on the servers hosting the repositories, you see it
when you want to check out the code.

At least that is how I understood Richard.

	Hannes

Re: MAINTAINERS file

[David Kastrup]

Jeremy Maitin-Shepard <jeremy@jeremyms.com> writes:

> More seriously, I think the goal of the GNU project should be to
> promote free software.

[...]

> You may argue that promoting the "GNU" name is important for promoting
> free software, but I don't buy that.

[...]

> I think the most significant barrier to greater appreciation for the
> idea of free software is the fact that it is very hard for
> non-programmers to understand or appreciate the idea of free software,
> and the vast majority of computer users are non-programmers.

Which is why something like the name with which something is mentioned
in the news to non-programmers makes an important difference.

I certainly consider the "GNU/Linux" naming issue a public relations
disaster for the FSF.  But it can't be denied that its primary goal,
rising awareness towards the GNU project (though not necessarily
sympathy) is being served by it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: MAINTAINERS file

[Richard Stallman]

    I certainly consider the "GNU/Linux" naming issue a public relations
    disaster for the FSF.  But it can't be denied that its primary goal,
    rising awareness towards the GNU project (though not necessarily
    sympathy) is being served by it.

Anyone who criticizes the GNU Project for asking people to say
"GNU/Linux" was not likely to become a supporter anyway.  At best he
might have been neutral.  We are far better off with one strong
supporter plus one person that hates us because of false beliefs
than with two people who don't think we have done anything important.

Re: MAINTAINERS file

[Richard Stallman]

    Favoring projects that have the "GNU" label suggests a real motivation
    of merely promoting the "GNU" name.

GNU is not just a label.  GNU is an operating system project.
Therefore, it is our policy that GNU package maintainers
should support other GNU packages when there is a good
opportunity to do so.

This is our policy.  You don't have to like it.

Re: MAINTAINERS file

[Bastien]

Karl Fogel <kfogel@red-bean.com> writes:

> "Juanma Barranquero" <lekktu@gmail.com> writes:
>> On Mon, Mar 3, 2008 at 1:55 PM, Romain Francoise <romain@orebokech.com> wrote:
>>>  Do you see the SCM switch (to bzr) happening before or after 23.1?
>>
>> And, it is decided then that it *will* be to Bazaar?
>
> Please, yes :-).  Stefan's right, it doesn't really matter, any of the
> distributed VCSs will be good for the Emacs team.
>
> http://bazaar-vcs.org/ for more information.
>
> We are not likely to regret it, and if we do, we can always try
> something else.

Many of you might know org-mode, which is part of Emacs:

  http://orgmode.org

Since there were many contributions around the core org.el file, we
switched to git a month ago and we don't regret it.

You can have a look at the git repository here:

  http://repo.or.cz/w/org-mode.git

We are still stabilizing some conventions about what goes where and who
does what, but the overall feeling is that the main developer (Carsten
Dominik) can rely on more people to help him.

-- 
Bastien

Re: MAINTAINERS file

[Stefan Monnier]

>> But the focus will be on 23.1.  As mentioned I'd like to enter feature
>> freeze for 23.1 by the beginning of the summer.  Until then I mostly
>> hope to include Emacs.app.

> Do you see the SCM switch (to bzr) happening before or after 23.1?

Depends how quickly 23.1 comes out,


        Stefan

merging Emacs.app (was Re: MAINTAINERS file)

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > But the focus will be on 23.1.  As mentioned I'd like to enter feature
  > freeze for 23.1 by the beginning of the summer.  Until then I mostly
  > hope to include Emacs.app.

Is there a definite schedule for merging Emacs.app?
The patch was posted here a while ago, and it got a lot of comments, but
we haven't heard back since...

What will happen with the Carbon port in CVS HEAD? It probably doesn't
even compile at the moment.

And more importantly will the 23.1 release depend on Emacs.app port
being completely functional?  One would hope that it won't. The reason
being the number of people doing actual work on that platform is tiny,
but the number of people reporting problems is huge...

Re: merging Emacs.app

[Stefan Monnier]

>> But the focus will be on 23.1.  As mentioned I'd like to enter feature
>> freeze for 23.1 by the beginning of the summer.  Until then I mostly
>> hope to include Emacs.app.

> Is there a definite schedule for merging Emacs.app?

No.  I just got in touch with Robert Adrian to try and figure out how
to proceed.

> What will happen with the Carbon port in CVS HEAD? It probably doesn't
> even compile at the moment.

What will happen to this port will in large part depend on whether or
not someone wants to maintain it.  The Emacs.app port is desirable not
only because it provides support for Mac OS X but also because it
provides support for GNUstep.

W.r.t whether we want the old Carbon port, the Carbon+Appkit port
(which I've only heard about), and/or the Emacs.app port all
together... well that makes for 4 different ports (counting the X11
version) for Mac OS X, which is a lot more than we need/want.

I think it's important for Emacs-23 to support Mac OS X about as well as
we did with Emacs-22.  So if Emacs.app is not yet ready and someone else
is willing to work on one of the Carbon ports, maybe we could keep it.

> And more importantly will the 23.1 release depend on Emacs.app port
> being completely functional?

No.


        Stefan

Re: merging Emacs.app

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > >> But the focus will be on 23.1.  As mentioned I'd like to enter feature
  > >> freeze for 23.1 by the beginning of the summer.  Until then I mostly
  > >> hope to include Emacs.app.
  > 
  > > Is there a definite schedule for merging Emacs.app?
  > 
  > No.  I just got in touch with Robert Adrian to try and figure out how
  > to proceed.
  > 
  > > What will happen with the Carbon port in CVS HEAD? It probably doesn't
  > > even compile at the moment.
  > 
  > What will happen to this port will in large part depend on whether or
  > not someone wants to maintain it.  The Emacs.app port is desirable not
  > only because it provides support for Mac OS X but also because it
  > provides support for GNUstep.
  > 
  > W.r.t whether we want the old Carbon port, the Carbon+Appkit port
  > (which I've only heard about), and/or the Emacs.app port all
  > together... well that makes for 4 different ports (counting the X11
  > version) for Mac OS X, which is a lot more than we need/want.
  > 
  > I think it's important for Emacs-23 to support Mac OS X about as well as
  > we did with Emacs-22.  So if Emacs.app is not yet ready and someone else
  > is willing to work on one of the Carbon ports, maybe we could keep it.

Hopefully the Mac OS X guys can get together and decide to support just
one of the non-X11 ports...

Re: merging Emacs.app

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 04 Mar 2008 21:04:19 -0800, Dan Nicolaescu <dann@ics.uci.edu> said:

> Hopefully the Mac OS X guys can get together and decide to support
> just one of the non-X11 ports...

For Emacs 22, I'll maintain the Carbon port (and possibly the
Carbon+AppKit port) unless my development environment for older
versions of Mac OS gets broken.

For Emacs 23, I don't have a plan to develop the Carbon port.
The Carbon+AppKit port may be for my personal use only (I already
have the Core Text font backend driver for Leopard, and I can
ignore multi-tty for my own use), unless the Cocoa/GNUstep port
fails to become good enough.

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

Re: merging Emacs.app

[Dan Nicolaescu]

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

  > >>>>> On Tue, 04 Mar 2008 21:04:19 -0800, Dan Nicolaescu <dann@ics.uci.edu> said:
  > 
  > > Hopefully the Mac OS X guys can get together and decide to support
  > > just one of the non-X11 ports...
  > 
  > For Emacs 22, I'll maintain the Carbon port (and possibly the
  > Carbon+AppKit port) unless my development environment for older
  > versions of Mac OS gets broken.
  > 
  > For Emacs 23, I don't have a plan to develop the Carbon port.
  > The Carbon+AppKit port may be for my personal use only (I already
  > have the Core Text font backend driver for Leopard, and I can
  > ignore multi-tty for my own use), unless the Cocoa/GNUstep port
  > fails to become good enough.

The question then is: would you be interested in using your expertise to
help the Emacs.app port get merged into trunk, and get into a state that
is at least as good as the Carbon port on emacs-22?

Re: merging Emacs.app

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 05 Mar 2008 08:05:36 -0800, Dan Nicolaescu <dann@ics.uci.edu> said:

>>> Hopefully the Mac OS X guys can get together and decide to support
>>> just one of the non-X11 ports...
>> 
>> For Emacs 22, I'll maintain the Carbon port (and possibly the
>> Carbon+AppKit port) unless my development environment for older
>> versions of Mac OS gets broken.
>> 
>> For Emacs 23, I don't have a plan to develop the Carbon port.  The
>> Carbon+AppKit port may be for my personal use only (I already have
>> the Core Text font backend driver for Leopard, and I can ignore
>> multi-tty for my own use), unless the Cocoa/GNUstep port fails to
>> become good enough.

> The question then is: would you be interested in using your
> expertise to help the Emacs.app port get merged into trunk, and get
> into a state that is at least as good as the Carbon port on
> emacs-22?

One may think that the two ports mainly differs in the APIs they use,
but what's really different between them is their fundamental design
and policy.  (Otherwise I wouldn't have tried to make another
Cocoa-based port.)

For example, the latest release of Emacs.app still doesn't quit with
C-g in certain situations such as `(while t)' or `M-! sleep 30 RET'.
Of course the Carbon port can quit there, but its strategy is not
directly applicable to the Cocoa port because of the difference in
their fundamental design.

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

Re: merging Emacs.app

[Dan Nicolaescu]

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

  > >>>>> On Wed, 05 Mar 2008 08:05:36 -0800, Dan Nicolaescu <dann@ics.uci.edu> said:
  > 
  > >>> Hopefully the Mac OS X guys can get together and decide to support
  > >>> just one of the non-X11 ports...
  > >> 
  > >> For Emacs 22, I'll maintain the Carbon port (and possibly the
  > >> Carbon+AppKit port) unless my development environment for older
  > >> versions of Mac OS gets broken.
  > >> 
  > >> For Emacs 23, I don't have a plan to develop the Carbon port.  The
  > >> Carbon+AppKit port may be for my personal use only (I already have
  > >> the Core Text font backend driver for Leopard, and I can ignore
  > >> multi-tty for my own use), unless the Cocoa/GNUstep port fails to
  > >> become good enough.
  > 
  > > The question then is: would you be interested in using your
  > > expertise to help the Emacs.app port get merged into trunk, and get
  > > into a state that is at least as good as the Carbon port on
  > > emacs-22?
  > 
  > One may think that the two ports mainly differs in the APIs they use,
  > but what's really different between them is their fundamental design
  > and policy.  (Otherwise I wouldn't have tried to make another
  > Cocoa-based port.)

Some of that experience should be portable though: ability to
debug/diagnose problems, porting some of the relevant lisp code should
all be useful.

Re: merging Emacs.app

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 05 Mar 2008 20:03:16 -0800, Dan Nicolaescu <dann@ics.uci.edu> said:

>>> The question then is: would you be interested in using your
>>> expertise to help the Emacs.app port get merged into trunk, and
>>> get into a state that is at least as good as the Carbon port on
>>> emacs-22?
>> 
>> One may think that the two ports mainly differs in the APIs they
>> use, but what's really different between them is their fundamental
>> design and policy.  (Otherwise I wouldn't have tried to make
>> another Cocoa-based port.)

> Some of that experience should be portable though: ability to
> debug/diagnose problems, porting some of the relevant lisp code
> should all be useful.

Maybe after the C-g issues have been solved, at least.

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

Re: merging Emacs.app

[Miles Bader]

BTW, what's the relationship between the "Emacs.app port" and
"Aquamacs"?

-Miles

-- 
Alone, adj. In bad company.

Re: merging Emacs.app

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 07 Mar 2008 12:20:35 +0900, Miles Bader <miles.bader@necel.com> said:

> BTW, what's the relationship between the "Emacs.app port" and
> "Aquamacs"?

IIUC, no relationship so far (the latter is based on the Carbon port),
but there may be in future.  There was also "Emacs on Aqua", and it is
the predecessor of "Emacs.app".

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

Re: merging Emacs.app

[Miles Bader]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
>> BTW, what's the relationship between the "Emacs.app port" and
>> "Aquamacs"?
>
> IIUC, no relationship so far (the latter is based on the Carbon port),
> but there may be in future.  There was also "Emacs on Aqua", and it is
> the predecessor of "Emacs.app".

So "Emacs.app" and "carbon emacs" are the underlying ports to OSX, and
"Aquamacs" is (currently) sort of "carbon emacs seriously tweaked to
make the UI more macish"?

-Miles

-- 
=====
(^o^;
(()))
*This is the cute octopus virus, please copy it into your sig so it can spread.

Re: merging Emacs.app

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 08 Mar 2008 12:46:35 +0900, Miles Bader <miles@gnu.org> said:

>>> BTW, what's the relationship between the "Emacs.app port" and
>>> "Aquamacs"?
>> 
>> IIUC, no relationship so far (the latter is based on the Carbon
>> port), but there may be in future.  There was also "Emacs on Aqua",
>> and it is the predecessor of "Emacs.app".

> So "Emacs.app" and "carbon emacs" are the underlying ports to OSX,
> and "Aquamacs" is (currently) sort of "carbon emacs seriously
> tweaked to make the UI more macish"?

Something like that, I guess.  But I'm not sure about the detail as
I've never tried Aquamacs Emacs.

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

Re: merging Emacs.app

[David Reitter]

On 8 Mar 2008, at 03:46, Miles Bader wrote:

> So "Emacs.app" and "carbon emacs" are the underlying ports to OSX, and
> "Aquamacs" is (currently) sort of "carbon emacs seriously tweaked to
> make the UI more macish"?

Yes, that is correct. Aquamacs is currently based on Carbon Emacs  
(usually the 22 branch in CVS).  I hope to switch to the Cocoa port  
once it is good enough, provides the same Lisp level API that Carbon  
has, and is in the Emacs CVS.

Re: merging Emacs.app

[Dan Nicolaescu]

Miles Bader <miles@gnu.org> writes:

  > YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
  > >> BTW, what's the relationship between the "Emacs.app port" and
  > >> "Aquamacs"?
  > >
  > > IIUC, no relationship so far (the latter is based on the Carbon port),
  > > but there may be in future.  There was also "Emacs on Aqua", and it is
  > > the predecessor of "Emacs.app".
  > 
  > So "Emacs.app" and "carbon emacs" are the underlying ports to OSX, and
  > "Aquamacs" is (currently) sort of "carbon emacs seriously tweaked to
  > make the UI more macish"?

There's another difference: Emacs.app is doing things the right way:
it is trying to get merged in Emacs.  No such attempt from Aquamacs until
now. On top of that Aquamacs has on it's website a Business School like
feature list where it shows how much better it is than Emacs, and how it
will continue to be like that because it will always use the latest
Emacs plus some changes on top...
It also has a place where it talks about the great contributions back to
Emacs <drumroll> bug reporting for Mac </drumroll>.
And bug reports from Aquamacs are sometime forwarded here, we do get to
do some debugging for Aquamacs too.

(On top of that the Aquamacs name is not that good... )

Re: merging Emacs.app

[David Reitter]

Dan,

On 8 Mar 2008, at 17:14, Dan Nicolaescu wrote:

> There's another difference: Emacs.app is doing things the right way:
> it is trying to get merged in Emacs.  No such attempt from Aquamacs  
> until
> now.

We cannot go for a merge, since we support a number of features for  
which an implementation does not exist on GNU/Linux.  That's why we  
can't even have "GNU Aquamacs".  Also, we have changed a number of  
defaults for customization variables. The new defaults often make  
Emacs more like other applications on the platform, but they do not  
make sense for users who are used to the "Emacs" way.  Often, people  
belonging to this group complain on the Aquamacs mailing lists, where  
we either advise them how to change the settings, or where to get the  
original GNU Emacs with its settings. Aquamacs strives for UI  
compatibility with other apps (primarily on the platform),  
prioritizing this over compatibility with other Emacs versions or  
Emacs on other platforms.  I don't think this is or should be a goal  
for the GNU Emacs project.

I submit changes where I see fit, but all of the Aquamacs changes are  
also openly visible in our CVS.  If you like to integrate specific  
features, then I'd be happy to explain specific changes.  I'd like to  
see as many people use those as possible, so do let me know.


> It also has a place where it talks about the great contributions  
> back to
> Emacs <drumroll> bug reporting for Mac </drumroll>.
> And bug reports from Aquamacs are sometime forwarded here, we do get  
> to
> do some debugging for Aquamacs too.

In almost all cases, it is me (and really only me) reproducing and  
tracing these bugs before or after reporting them.  If you prefer me  
to ignore and swallow those user's bug reports, then Stefan and Chong  
can let me know.

Re: merging Emacs.app

[Dan Nicolaescu]

David Reitter <david.reitter@gmail.com> writes:

  > On 8 Mar 2008, at 17:14, Dan Nicolaescu wrote:
  > 
  > > There's another difference: Emacs.app is doing things the right way:
  > > it is trying to get merged in Emacs.  No such attempt from Aquamacs
  > > until
  > > now.
  > 
  > We cannot go for a merge, since we support a number of features for
  > which an implementation does not exist on GNU/Linux.  That's why we
  > can't even have "GNU Aquamacs".  

Sorry, but it's impossible to believe that there's _nothing_ that can be
contributed back. 
(And again the comments about the superiority to Emacs on the website
are mildly annoying).

  > I submit changes where I see fit, but all of the Aquamacs changes are
  > also openly visible in our CVS.  If you like to integrate specific
  > features, then I'd be happy to explain specific changes.  I'd like to
  > see as many people use those as possible, so do let me know.

Very few people here have access to Macs, so we can't test whatever is
visible there.  It is better that merge requests originate from people
that know the features/code.

  > > It also has a place where it talks about the great contributions
  > > back to
  > > Emacs <drumroll> bug reporting for Mac </drumroll>.
  > > And bug reports from Aquamacs are sometime forwarded here, we do get
  > > to
  > > do some debugging for Aquamacs too.
  > 
  > In almost all cases, it is me (and really only me) reproducing and
  > tracing these bugs before or after reporting them.  If you prefer me
  > to ignore and swallow those user's bug reports,

We prefer to hear about bugs in emacs-22.1, EMACS_22_BASE, and CVS HEAD,
so it is better to reproduces the bugs on one of those versions using
emacs -Q, and then report it here.

Re: merging Emacs.app

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 1320 bytes --]

On 8 Mar 2008, at 18:34, Dan Nicolaescu wrote:
>>
>> In almost all cases, it is me (and really only me) reproducing and
>> tracing these bugs before or after reporting them.  If you prefer me
>> to ignore and swallow those user's bug reports,
>
> We prefer to hear about bugs in emacs-22.1, EMACS_22_BASE, and CVS  
> HEAD,
> so it is better to reproduces the bugs on one of those versions using
> emacs -Q, and then report it here.

Sure, that's what I usually do. However, occasionally I can't  
reproduce or even understand reports without the right knowledge.   
There, collaboration is needed in the sense that some experts need to  
give the right hint, as was just the case for this C++ mode bug.  This  
kind of collaboration has worked arguably well for everyone involved  
since 2005, and we have squashed a number of bugs in the Emacs 22 code  
base (not in Aquamacs) this way.  So, I see no need to change the  
modus operandi at this point.

PS.: Yes, the projects compete in some ways, and they collaborate in  
others.  The publicity reflects that.   Aquamacs has more than 10,000  
different users every week, who have chosen to use the Aquamacs  
variant of GNU Emacs.  These new users are new GNU Emacs users, too,  
and they reflect the great success for everyone that has contributed  
to Emacs 22.1.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

The Aquamacs fork (was Re: merging Emacs.app)

[Dan Nicolaescu]

David Reitter <david.reitter@gmail.com> writes:

  > On 8 Mar 2008, at 18:34, Dan Nicolaescu wrote:
  > >>
  > >> In almost all cases, it is me (and really only me) reproducing and
  > >> tracing these bugs before or after reporting them.  If you prefer me
  > >> to ignore and swallow those user's bug reports,
  > >
  > > We prefer to hear about bugs in emacs-22.1, EMACS_22_BASE, and CVS
  > > HEAD,
  > > so it is better to reproduces the bugs on one of those versions using
  > > emacs -Q, and then report it here.
  > 
  > Sure, that's what I usually do. However, occasionally I can't
  > reproduce or even understand reports without the right knowledge.
  > There, collaboration is needed in the sense that some experts need to
  > give the right hint, as was just the case for this C++ mode bug.  This
  > kind of collaboration has worked arguably well for everyone involved
  > since 2005, and we have squashed a number of bugs in the Emacs 22 code
  > base (not in Aquamacs) this way.  So, I see no need to change the
  > modus operandi at this point.
  > 
  > PS.: Yes, the projects compete in some ways, and they collaborate in
  > others.  The publicity reflects that.

You seem to be arguing that forking Emacs is a good idea (and that is
what Aquamacs effectively is a fork).  You won't find many people (if
any) here agreeing with that.  And the fact that no significant attempt
has been made until now to merge features from Aquamacs to Emacs.

It is your right under GPL to fork, but that does not mean it is the
best thing to do.
It is much better to cooperate and try to add features specific to the
MacOS port back to Emacs.  This is what has made Emacs successful until
now, hundreds of people working on hundreds of different types of
machines and OSes have all added features.

Re: merging Emacs.app

[David Kastrup]

David Reitter <david.reitter@gmail.com> writes:

> Aquamacs strives for UI compatibility with other apps (primarily on
> the platform), prioritizing this over compatibility with other Emacs
> versions or Emacs on other platforms.  I don't think this is or should
> be a goal for the GNU Emacs project.

This should likely be done using customization themes.  There is no
reason that a user accustomed to Windows should not be able to elicit a
Windows-like behavior on MacOS and the other way round without changing
binaries.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: merging Emacs.app

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 08 Mar 2008 19:40:38 +0100, David Kastrup <dak@gnu.org> said:

>> Aquamacs strives for UI compatibility with other apps (primarily on
>> the platform), prioritizing this over compatibility with other
>> Emacs versions or Emacs on other platforms.  I don't think this is
>> or should be a goal for the GNU Emacs project.

> This should likely be done using customization themes.  There is no
> reason that a user accustomed to Windows should not be able to
> elicit a Windows-like behavior on MacOS and the other way round
> without changing binaries.

So, the customization themes seem to overlap with Aquamacs features.
Then I wonder what "Aquamacs - (Emacs + customization theme +
packaging)" is.  That might be a candidate of feedbacks.

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

Re: merging Emacs.app

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 8 Mar 2008 17:46:39 +0000, David Reitter <david.reitter@gmail.com> said:

> In almost all cases, it is me (and really only me) reproducing and
> tracing these bugs before or after reporting them.  If you prefer me
> to ignore and swallow those user's bug reports, then Stefan and
> Chong can let me know.

Of course, you shouldn't swallow bug reports.  And I think you
shouldn't swallow donations, either.

Are you distributing some of donations you gained from Aquamacs Emacs
to GNU project and elisp package authors?  I couldn't find an explicit
statement about that.

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

Re: merging Emacs.app

[David Kastrup]

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

>>>>>> On Sat, 8 Mar 2008 17:46:39 +0000, David Reitter
>>>>>> <david.reitter@gmail.com> said:
>
>> In almost all cases, it is me (and really only me) reproducing and
>> tracing these bugs before or after reporting them.  If you prefer me
>> to ignore and swallow those user's bug reports, then Stefan and
>> Chong can let me know.
>
> Of course, you shouldn't swallow bug reports.  And I think you
> shouldn't swallow donations, either.
>
> Are you distributing some of donations you gained from Aquamacs Emacs
> to GNU project and elisp package authors?  I couldn't find an explicit
> statement about that.

Well, if the donations I have been swallowing on behalf of the AUCTeX
project are anything to go by, there is less to be expected than a case
of beer per year.  I have no qualms pocketing that (has not happened for
a long time, though).  It is far less than what I pay in order to talk
at conferences where I help people use the software I am maintaining.

If David gets substantially more money out of Aquamacs than he sinks
into it, he really needs to tell me his secret.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: merging Emacs.app

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 1442 bytes --]

On 9 Mar 2008, at 13:27, David Kastrup wrote:

> If David gets substantially more money out of Aquamacs than he sinks
> into it, he really needs to tell me his secret.

Unfortunately I haven't found that secret either.

I do think that adequate compensation is important quite generally.   
The usual options did not appear promising. Asking for very low  
download fees ($1-2 per download) doesn't work because micropayment  
systems are missing, and because it encourages no-value added forks.   
Selling a manual or so doesn't work because the revenue probably  
doesn't even compensate the author of the book that hasn't been  
written (and costs money to be printed).   Selling additional  
consulting services is a no-go either because Emacs is used at  
universities or by coders, but not much by enough large companies who  
would pay consultants to write Lisp code.  I like the user-driven  
"wishlist" systems where users promise sums for specific features, but  
I haven't seen them work for any project yet.

Now, money isn't the main motivator, even though it pays the rent.   
Work on free software is, in my case, booked under "academic service",  
about like when I review papers for conferences and the occasional  
journal every now and then.  But it also means that I do what's fun  
and productive, and I try to avoid other things.

But in the long run, the movement needs a better answer to the  
compensation question.


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: merging Emacs.app

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 9 Mar 2008 14:30:35 +0000, David Reitter <david.reitter@gmail.com> said:

>> If David gets substantially more money out of Aquamacs than he
>> sinks into it, he really needs to tell me his secret.

> Unfortunately I haven't found that secret either.

> I do think that adequate compensation is important quite generally.

Do you think donators are correctly distinguishing Aquamacs's own work
from others' work?

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

Re: merging Emacs.app

[Adrian Robert]

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

> One may think that the two ports mainly differs in the APIs they use,
> but what's really different between them is their fundamental design
> and policy.  (Otherwise I wouldn't have tried to make another
> Cocoa-based port.)
> 
> For example, the latest release of Emacs.app still doesn't quit with
> C-g in certain situations such as `(while t)' or `M-! sleep 30 RET'.
> Of course the Carbon port can quit there, but its strategy is not
> directly applicable to the Cocoa port because of the difference in
> their fundamental design.

It is true that there are design differences btwn the ports, many arising
because NeXTstep is an OO API and the port tried to use those facilities
effectively from the beginning.  (And there are pros and cons of this, since
it causes some code differences to other ports built around non-OO APIs.)
However that is unrelated to this Ctrl-G issue.

The event handling in the Emacs.app is slightly different from the Carbon
code, but in my understanding these shouldn't prevent similar Ctrl-G
sensitivity.  However by default Emacs.app does not define NO_SOCK_SIGIO,
while Carbon does.  Turning it on (add --enable-cocoa-experimental-ctrl- g to
configure args) improves Ctrl-G sensitivity, but brings some undesired side
effects, related to scrolling and multi-frame switching.  It is an open TODO
to address these side effects and also make a few other code changes to bring
the sensitivity fully up to the Carbon level, but I would be surprised if it
needed changes to fundamental design to do this.

BTW, a very closely related improvement needed is to correctly handle input
when GUI and terminal windows are simultaneously active.

-Adrian

Re: merging Emacs.app

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 10 Mar 2008 10:06:22 +0000 (UTC), Adrian Robert <Adrian.B.Robert@gmail.com> said:

>> One may think that the two ports mainly differs in the APIs they
>> use, but what's really different between them is their fundamental
>> design and policy.  (Otherwise I wouldn't have tried to make
>> another Cocoa-based port.)
>> 
>> For example, the latest release of Emacs.app still doesn't quit
>> with C-g in certain situations such as `(while t)' or `M-! sleep 30
>> RET'.  Of course the Carbon port can quit there, but its strategy
>> is not directly applicable to the Cocoa port because of the
>> difference in their fundamental design.

> It is true that there are design differences btwn the ports, many
> arising because NeXTstep is an OO API and the port tried to use
> those facilities effectively from the beginning.  (And there are
> pros and cons of this, since it causes some code differences to
> other ports built around non-OO APIs.)  However that is unrelated to
> this Ctrl-G issue.

I don't mean OO vs. non-OO, which is of course unrelated to C-g, by
"difference in their fundamental design".

> The event handling in the Emacs.app is slightly different from the
> Carbon code, but in my understanding these shouldn't prevent similar
> Ctrl-G sensitivity.  However by default Emacs.app does not define
> NO_SOCK_SIGIO, while Carbon does.  Turning it on (add
> --enable-cocoa-experimental-ctrl- g to configure args) improves
> Ctrl-G sensitivity, but brings some undesired side effects, related
> to scrolling and multi-frame switching.  It is an open TODO to
> address these side effects and also make a few other code changes to
> bring the sensitivity fully up to the Carbon level, but I would be
> surprised if it needed changes to fundamental design to do this.

I can find so many (indirect) Feval calls from ns_read_socket and some
of them seem to be difficult to get rid of because of its fundamental
design.  In Emacs 22 at least, read_socket_hook may be called from a
signal handler in most environments.  As the Lisp interpreter is not
designed to be reentrant, you cannot call Feval from read_socket_hook
directly or indirectly (that's why both X11 and Carbon ports increment
`handling_signal' in their read_socket_hook's to make Feval abort).
You don't see such a problem in the Cocoa/GNUstep port unless
NO_SOCK_SIGIO is defined, but C-g is not handled properly.

I'm not sure if SYNC_INPUT changes the situation in Emacs 23.  But I
would rather choose the strategy that is working in other platforms
than taking a risk of introducing a untested one for nontrivial issues
such as C-g.

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

Re: merging Emacs.app

[Adrian Robert]

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

> I can find so many (indirect) Feval calls from ns_read_socket and some
> of them seem to be difficult to get rid of because of its fundamental
> design.  In Emacs 22 at least, read_socket_hook may be called from a
> signal handler in most environments.  As the Lisp interpreter is not
> designed to be reentrant, you cannot call Feval from read_socket_hook
> directly or indirectly (that's why both X11 and Carbon ports increment
> `handling_signal' in their read_socket_hook's to make Feval abort).
> You don't see such a problem in the Cocoa/GNUstep port unless
> NO_SOCK_SIGIO is defined, but C-g is not handled properly.

Hmm, I'll look into getting rid of the Fevals then.  Still, the side effects
 I spoke of are (I believe) unrelated to this.

thanks,
Adrian

Re: merging Emacs.app

[Stefan Monnier]

> I'm not sure if SYNC_INPUT changes the situation in Emacs 23.  But I
> would rather choose the strategy that is working in other platforms
> than taking a risk of introducing a untested one for nontrivial issues
> such as C-g.

SYNC_INPUT doesn't make much difference here: indeed the code is not
executed from the signal handler any more, but it's still handled at
fairly arbitrary points in the code, many of whom do not allow execution
of elisp code.  So w.r.t execution of elisp code from read_socket_hook,
it's still a big no-no.


        Stefan

Re: MAINTAINERS file

[Richard Stallman]

    But the focus will be on 23.1.  As mentioned I'd like to enter feature
    freeze for 23.1 by the beginning of the summer.  Until then I mostly
    hope to include Emacs.app.

I hope that the Rmail mbox branch can be included in 23 also.

Re: MAINTAINERS file

[Stefan Monnier]

>     But the focus will be on 23.1.  As mentioned I'd like to enter feature
>     freeze for 23.1 by the beginning of the summer.  Until then I mostly
>     hope to include Emacs.app.

> I hope that the Rmail mbox branch can be included in 23 also.

That would be fine by me, but is there progress on this front?
I haven't heard anything about it for ages now and last I heard it
wasn't ready for prime time.


        Stefan

Re: MAINTAINERS file

[Richard Stallman]

    That would be fine by me, but is there progress on this front?
    I haven't heard anything about it for ages now and last I heard it
    wasn't ready for prime time.

Part of what maintainers do is inspire and convince people to make the
necessary progress so that desired features can be installed.

Re: MAINTAINERS file

[Bastien]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>     But the focus will be on 23.1.  As mentioned I'd like to enter feature
>>     freeze for 23.1 by the beginning of the summer.  Until then I mostly
>>     hope to include Emacs.app.
>
>> I hope that the Rmail mbox branch can be included in 23 also.
>
> That would be fine by me, but is there progress on this front?

I think the development on the Rmail mbox branch stopped.

As I am working on the EasyPG support for Rmail, and getting more
familiar with the Rmail code, I would be glad to revive this branch.
But since I was not part of the previous rewrite effort, it is quite
difficult to get an overview of what has been done so far and what 
still needs to be done.

Any direction from previous developers would be great.

Thanks,

-- 
Bastien

Re: MAINTAINERS file

[Xavier Maillard]

   Stefan Monnier <monnier@iro.umontreal.ca> writes:

   >>     But the focus will be on 23.1.  As mentioned I'd like to enter feature
   >>     freeze for 23.1 by the beginning of the summer.  Until then I mostly
   >>     hope to include Emacs.app.
   >
   >> I hope that the Rmail mbox branch can be included in 23 also.
   >
   > That would be fine by me, but is there progress on this front?

   I think the development on the Rmail mbox branch stopped.

   As I am working on the EasyPG support for Rmail, and getting more
   familiar with the Rmail code, I would be glad to revive this branch.
   But since I was not part of the previous rewrite effort, it is quite
   difficult to get an overview of what has been done so far and what 
   still needs to be done.

Sadly I haven't eard from Enrik and Alex for ages. I know there
is an embryon of a working mbox branch 8but* it is far from
complete.

What is not quite clear to me is what do people expect from this
"rewrite effort" exactly ?

I guess the primary goal is to switch to a more "popular" file
storage but Alex and Enrik have also worked on the MIME part to,
at last, have a decent MIME support (even basic) for us, Rmail users.

   Any direction from previous developers would be great.

/me pokes Alex too ;)

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Re: MAINTAINERS file

[Stefan Monnier]

>>> But the focus will be on 23.1.  As mentioned I'd like to enter feature
>>> freeze for 23.1 by the beginning of the summer.  Until then I mostly
>>> hope to include Emacs.app.
>> 
>>> I hope that the Rmail mbox branch can be included in 23 also.
>> 
>> That would be fine by me, but is there progress on this front?

>    I think the development on the Rmail mbox branch stopped.

>    As I am working on the EasyPG support for Rmail, and getting more
>    familiar with the Rmail code, I would be glad to revive this branch.
>    But since I was not part of the previous rewrite effort, it is quite
>    difficult to get an overview of what has been done so far and what 
>    still needs to be done.

> Sadly I haven't eard from Enrik and Alex for ages. I know there
> is an embryon of a working mbox branch 8but* it is far from
> complete.

> What is not quite clear to me is what do people expect from this
> "rewrite effort" exactly ?

To me the first goal should be just to change the underlying format from
BABYL to standard mbox so that it can interact with other programs.

> I guess the primary goal is to switch to a more "popular" file
> storage but Alex and Enrik have also worked on the MIME part to,
> at last, have a decent MIME support (even basic) for us, Rmail users.

MIME additions would be good.  Ideally, this should share a lot of code
with the Gnus MIME code (some of which is also used by MH-E IIUC).


        Stefan

Re: MAINTAINERS file

[Richard Stallman]

    What is not quite clear to me is what do people expect from this
    "rewrite effort" exactly ?

    I guess the primary goal is to switch to a more "popular" file
    storage but Alex and Enrik have also worked on the MIME part to,
    at last, have a decent MIME support (even basic) for us, Rmail users.

Both of these are desirable improvements, but there is no need for one
of them to wait for the other.

Since using mbox files is mostly working, I think we should finish
that and get it installed.  Once that is installed, we could work on
better mime support.

Re: MAINTAINERS file

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> To tell you the truth, I don't think we know yet how things will run.
> But here's how I see it:
>
> - as a maintainer, I have the responsability to make sure bug reports do
>   not get lost.  That's my #1 preoccupation for now.  Which also means:
>   please report bugs to emacsbugs.donarmstrong.com, please subscribe the
>   the emacsbugs mailing list, and please respond to bugs on that
>   mailing list rather than on the emacs-pretest-bug or
>   bug-gnu-emacs lists.
>
> - I do not intend to set up any new rules and procedures.
>
> - I think Chong generally agrees.

What my esteemed colleague said ;-)