New maintainer

New maintainer

[Bastien]

Dear all,

I'm stepping down as the Org maintainer.

Carsten accepted to step up, if the community agrees.
Please raise your thumbs up or your concerns, if any.

I'm glad I had this opportunity to work as "Robin" and
I'm even more glad "Batman" may strike back!

:)

-- 
 Bastien

Re: New maintainer

[Jambunathan K]

> Carsten accepted to step up, if the community agrees.
> Please raise your thumbs up or your concerns, if any.

To the new maintainer, 

My changes to ox-html.el and ox-odt.el are not assigned to FSF.  So
please correct the headers of these file to reflect the reality.  

Also be respectful of my wish and refrain from merging my changes to
Emacs.  It is a polite request.  Write to me if you have questions.

Jambunathan K.

Re: New maintainer

[John Hendy]

On Thu, Apr 18, 2013 at 12:10 PM, Jambunathan K <kjambunathan@gmail.com> wrote:
>
>> Carsten accepted to step up, if the community agrees.
>> Please raise your thumbs up or your concerns, if any.
>
> To the new maintainer,
>
> My changes to ox-html.el and ox-odt.el are not assigned to FSF.  So
> please correct the headers of these file to reflect the reality.
>
> Also be respectful of my wish and refrain from merging my changes to
> Emacs.  It is a polite request.  Write to me if you have questions.

I'd like some definitive resolution to this issue or list-wide
understanding of where things are at. I've been trying to follow your
saga, and my understanding is:

- You signed over contribution rights to FSF at one point. Is this correct?

- You have contacted FSF (or Emacs?) and requested that these rights
be revoked/reversed?

- Has the FSF (or Emacs?) provided any statement/ruling on whether or
not they will honor your request?

I hear you, and you definitely make it known that you would like to
undo what you once did... but my perception is that your emails speak
as though there is no agreement in place at all... but you *did* sign
the contract at one point, right? I've not contributed to code, so
I've never seen the FSF papers and don't really know what they
entail... but if they are signing away rights to future contributions,
it would seem that your work is under that umbrella until *they*
provide confirmation that the umbrella no longer exists (*and* no
longer exists retroactively).

Just trying to reconcile my understanding of your situation with how
you write about it.


Thanks,
John

>
> Jambunathan K.
>

Re: New maintainer

[Bastien]

Please let's not reopen this issue.

Jambunathan signed the FSF copyright assignment for his past and
future changes to Emacs code.  He claims that he can retract this
assignment for changes he made against some Emacs files.  FSF says
this is not possible.

And it does not take too big a brain to understand why: if people
were allowed to retract their assignment when they want for changes
that have been published, the copyright assignment process would
undermine the whole purpose of the GPL license, which is to make
it possible to let *others* contribute to free code.

If there were a problem, it would be a problem for Emacs, not for
upstream Org-mode, which can include any GPL code.  But there is
no problem.  Just someone upset, in bad need for a ban.

-- 
 Bastien

Re: New maintainer

[Jambunathan K]

Bastien <bzg@gnu.org> writes:

> And it does not take too big a brain to understand why: if people
> were allowed to retract their assignment when they want for changes
> that have been published, the copyright assignment process would
> undermine the whole purpose of the GPL license, which is to make
> it possible to let *others* contribute to free code.

As a maintainer of GNU project, I expect that you should have a basic
understanding of the purpose of the copyright assignment and GPL
license.  From what I read above, I am not convinced that you have the
right understanding.  Your articulation is clearly confusing and falling
short.

See 

        http://www.gnu.org/licenses/gpl-faq.html#AssignCopyright

You assign copyright to FSF so that you don't have to enforce GPL.  By
assigning, one outsources the legal work of actual enforcing to FSF.
Single holder of rights just makes the legal procedures lot more easy.

A contract that cannot be enforced is worthless.  A license that you
cannot enforce is equally so.  

FSF says, assign me the rights, I will go after all the violators and
force them to comply with GPL.

Jambunathan K.

Re: New maintainer

[Alan L Tyree]

Jambunathan K writes:

> Bastien <bzg@gnu.org> writes:
>
>> And it does not take too big a brain to understand why: if people
>> were allowed to retract their assignment when they want for changes
>> that have been published, the copyright assignment process would
>> undermine the whole purpose of the GPL license, which is to make
>> it possible to let *others* contribute to free code.
>
> As a maintainer of GNU project, I expect that you should have a basic
> understanding of the purpose of the copyright assignment and GPL
> license.  From what I read above, I am not convinced that you have the
> right understanding.  Your articulation is clearly confusing and falling
> short.

As a former teacher of copyright law (University of Sydney), I think
that Bastien displays a very clear understanding of the effects of
copyright assignment. Your understanding is less than clear.  Bastien
gets a "Distinction" in my class. You do not.

Of course, I know that you will think that I am confused.

Bastien, thanks for your patience and help during your time in the
hotseat. You've done a marvelous job.

>
> See 
>
>         http://www.gnu.org/licenses/gpl-faq.html#AssignCopyright
>
> You assign copyright to FSF so that you don't have to enforce GPL.  By
> assigning, one outsources the legal work of actual enforcing to FSF.
> Single holder of rights just makes the legal procedures lot more easy.
>
> A contract that cannot be enforced is worthless.  A license that you
> cannot enforce is equally so.  
>
> FSF says, assign me the rights, I will go after all the violators and
> force them to comply with GPL.
>
> Jambunathan K.


-- 
Alan L Tyree           http://www2.austlii.edu.au/~alan
Tel:  04 2748 6206     sip:172385@iptel.org

Re: New maintainer

[Jambunathan K]

Alan L Tyree <alantyree@gmail.com> writes:

> Of course, I know that you will think that I am confused.

You are not only confused. You are in hurry and in grave error.

I am quoting an extract of Bastien's words,

        the copyright assignment process would undermine the whole
        purpose of the GPL license

It is wrong to say copyright assigment will undermine the purpose of GPL
license.  Copyright assignment is there to bolster the enforcement of
GPL.  I provided a reference.

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

My claim is that there is no assignment.  Because out of my own
initiative I informed FSF that "this work is not covered by contract"
and also cancelled the assignment.

How do you interpret the following block extracted from my assignment

    ,----
    | 2. Developer will report occasionally, on Developer’s initiative
    | and whenever requested by FSF, the changes and/ or enhancements
    | which are covered by this contract, and (to the extent known to
    | Developer) any outstanding rights, or claims of rights, of any
    | person, that might be adverse to the rights of Developer or FSF
    | or to the purpose of this contract.
    `----

FSF clearly side-steps the important question - when is a work actually
assigned.  Assignment is not a process but an event tied to specific
time and date.

Will you disagree if I claim - "The intent to act is not the act
itself".  Replacement act with <whatever>.

Jambunathan K.

Re: New maintainer

[Alan L Tyree]

Jambunathan K writes:

> Alan L Tyree <alantyree@gmail.com> writes:
>
>> Of course, I know that you will think that I am confused.
>
> You are not only confused. You are in hurry and in grave error.

I thought so. Thanks so much for clearing this up for me.

>
> I am quoting an extract of Bastien's words,
>
>         the copyright assignment process would undermine the whole
>         purpose of the GPL license
>
> It is wrong to say copyright assigment will undermine the purpose of GPL
> license.  Copyright assignment is there to bolster the enforcement of
> GPL.  I provided a reference.
>
> ----------------------------------------------------------------
>
> My claim is that there is no assignment.  Because out of my own
> initiative I informed FSF that "this work is not covered by contract"
> and also cancelled the assignment.
>
> How do you interpret the following block extracted from my assignment
>
>     ,----
>     | 2. Developer will report occasionally, on Developer’s initiative
>     | and whenever requested by FSF, the changes and/ or enhancements
>     | which are covered by this contract, and (to the extent known to
>     | Developer) any outstanding rights, or claims of rights, of any
>     | person, that might be adverse to the rights of Developer or FSF
>     | or to the purpose of this contract.
>     `----
>
> FSF clearly side-steps the important question - when is a work actually
> assigned.  Assignment is not a process but an event tied to specific
> time and date.
>
> Will you disagree if I claim - "The intent to act is not the act
> itself".  Replacement act with <whatever>.
>
> Jambunathan K.


-- 
Alan L Tyree           http://www2.austlii.edu.au/~alan
Tel:  04 2748 6206     sip:172385@iptel.org

Re: New maintainer

[Tassilo Horn]

Jambunathan K <kjambunathan@gmail.com> writes:

> How do you interpret the following block extracted from my assignment
>
>     ,----
>     | 2. Developer will report occasionally, on Developer’s initiative
>     | and whenever requested by FSF, the changes and/ or enhancements
>     | which are covered by this contract, and (to the extent known to
>     | Developer) any outstanding rights, or claims of rights, of any
>     | person, that might be adverse to the rights of Developer or FSF
>     | or to the purpose of this contract.
>     `----

Well, the FSF's intention here is to make sure that contributors report
back when they change employers, and the new employer doesn't want that
his employees contribute to some GNU project (maybe because that project
is in the same business as the company).  So I think of that more of a
safety measure in order not to run into long-running, painful lawsuits.

> FSF clearly side-steps the important question - when is a work
> actually assigned.  Assignment is not a process but an event tied to
> specific time and date.

As far as I understand it (just after reading one of my FSF CAs), the
changes you apply to a program where you've assigned past & future
changes are assigned as soon as they are written.  They don't need to be
published, distributed, placed in a special repository location, etc.

Bye,
Tassilo

Re: New maintainer

[Jambunathan K]

Tassilo Horn <tsdh@gnu.org> writes:

> Jambunathan K <kjambunathan@gmail.com> writes:
>
>> How do you interpret the following block extracted from my assignment
>>
>>     ,----
>>     | 2. Developer will report occasionally, on Developer’s initiative
>>     | and whenever requested by FSF, the changes and/ or enhancements
>>     | which are covered by this contract, and (to the extent known to
                                             ^^^
                                             ^^^
                                             ^^^
>>     | Developer) any outstanding rights, or claims of rights, of any
>>     | person, that might be adverse to the rights of Developer or FSF
>>     | or to the purpose of this contract.
>>     `----
>
> Well, the FSF's intention here is to make sure that contributors report
> back when they change employers, and the new employer doesn't want that
> his employees contribute to some GNU project (maybe because that project
> is in the same business as the company).  So I think of that more of a
> safety measure in order not to run into long-running, painful
> lawsuits.

Your interpretation is too narrow.  The phrase "and" (marked above)
there makes all the difference.

My reading of the above para and Richard's response down below are
consistent.

  ,----  http://lists.gnu.org/archive/html/emacs-devel/2013-04/msg00066.html
  | If a contributor wants to specify precisely which changes are
  | assigned, he, she or it can talk with the FSF about it.  We can
  | work something out.  However, we'd prefer to be able to use all of
  | someone's changes without specific arrangements.
  `----

>> FSF clearly side-steps the important question - when is a work
>> actually assigned.  Assignment is not a process but an event tied to
>> specific time and date.
>
> As far as I understand it (just after reading one of my FSF CAs), the
> changes you apply to a program where you've assigned past & future
> changes are assigned as soon as they are written.  They don't need to be
> published, distributed, placed in a special repository location, etc.

Assignment of rights is for the purpose of defending GPL.  It is *not*
and *cannot* be an annexation policy.  What you state above amounts to
annexation policy.

Assignment of rights is my prerogative.  I can do it selectively or
cancel it.  FSF cannot interfere with what is an individual decision.

I will only quote an authoritative and responsible source. Focus on last
sentence in the below quote.

    ,----  http://lwn.net/Articles/543436/
    |
    | Anyway, it's unfortunate the Corbet's article above doesn't
    | reiterate the advantages of assigning to FSF to
    | developers. Specifically, the FSF takes on the obligation of being
    | the publisher of the code (which can sometimes be a dangerous act
    | in today's world), and also, FSF handles enforcement of the GPL
    | for the codebase. Finally, FSF gives a liberal license back to the
    | developer (i.e., Jambunathan could have always made proprietary
    | software out of his own assigned works after doing the
    | assignment), and FSF further promises never to publish a
    | proprietary version of the software itself.
    |
    `----

I interpret "proprietary" above to mean "any work (available to public,
it is GPL right?) that is not part of Emacs distribution".

Theoretically speaking, it is OK to have future assignment in place
*and* have works that are assigned, as well as non-assigned
*simultaneously*.  If a work is not part of Emacs, then it is "not
assigned" to FSF.  Simple and practical definition.

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

It is also important to note that the above paragraph from a FSF board
member is in some conflict with RMS's own claim.

    ,---- http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00409.html
    |
    | A diff for Emacs is always a change to Emacs.  I will think about
    | the questions raised by a separate Lisp file.
    |
    `----

In my opinion, the most appropriate thing to state would be 

   "A diff to Emacs submitted to the official channels of the suite -
    either the maintainer, mailing list or bug subsystem, *unless stated
    otherwise* is potentially part of Emacs, in a non-revocable way."

It will be inappropriate for anyone to claim, my local changes to
doc-view.el that I share with a co-worker is a diff to Emacs and hence
part of Emacs.  A change is either part of Emacs or not.  When I say
Emacs, I mean the official GNU Emacs distributed from gnu.org.

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

Now the primary part of current dispute is that it falls in a grey area

    1. My files are new.

    2. "Org in Emacs Bzr trunk" is not the same as "Org outside of Emacs
        trunk".  One is "part of Emacs" while the other is "not part of
        Emacs".  There is a clear dichotomy here.  It is easy to answer
        "Is this file part of Emacs?" with a "Yes" or "No".  Saying that
        a file is intended to be part of Emacs is equivalent to saying
        "No."

        Thought experiment: You cannot claim ownership of a house merely
        because the other party "intended" to sell it.

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

I will advise all vigorous enterprising young men *never* to assign his
rights to any organization other than his own.

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

"Intent to act is not the act itself"
Jambunathan K,
        
> Bye,
> Tassilo

Re: New maintainer

[Jambunathan K]

Jambunathan K <kjambunathan@gmail.com> writes:

>> Well, the FSF's intention here is to make sure that contributors report
>> back when they change employers, and the new employer doesn't want that
>> his employees contribute to some GNU project (maybe because that project
>> is in the same business as the company).  So I think of that more of a
>> safety measure in order not to run into long-running, painful
>> lawsuits.

You are missing out an important aspect - that of "enforcement".  An
organization will most likely "choose to enforce" but an RJH (like me)
won't.

That is, the employer can (presumably) send his lawyer to a the court
with the employment contract and say

    "Employee can assign rights (and FSF can very well accept it).  But
     the assignation has no legal validity because it is not within
     employee's right to do so.  Employee himself agreed that he will
     abide by <whatever> while on our pay.  We are asserting and
     enforcing our position now."

For an assignment to have legal validity, multiple parties - FSF,
contributor and contributor's employer - should *converge*.

When there is no convergence of *all* parties , the "assignment" stands
on weaker grounds.

Standing on weaker ground is precisely what FSF wants to avoid at all
costs.

Jambunathan K.

Re: New maintainer

[Carsten Dominik]

On 21.4.2013, at 10:06, Jambunathan K <kjambunathan@gmail.com> wrote:

> Jambunathan K <kjambunathan@gmail.com> writes:
> 
>>> Well, the FSF's intention here is to make sure that contributors report
>>> back when they change employers, and the new employer doesn't want that
>>> his employees contribute to some GNU project (maybe because that project
>>> is in the same business as the company).  So I think of that more of a
>>> safety measure in order not to run into long-running, painful
>>> lawsuits.
> 
> You are missing out an important aspect - that of "enforcement".  An
> organization will most likely "choose to enforce" but an RJH (like me)
> won't.
> 
> That is, the employer can (presumably) send his lawyer to a the court
> with the employment contract and say
> 
>    "Employee can assign rights (and FSF can very well accept it).  But
>     the assignation has no legal validity because it is not within
>     employee's right to do so.  Employee himself agreed that he will
>     abide by <whatever> while on our pay.  We are asserting and
>     enforcing our position now."
> 
> For an assignment to have legal validity, multiple parties - FSF,
> contributor and contributor's employer - should *converge*.
> 
> When there is no convergence of *all* parties , the "assignment" stands
> on weaker grounds.
> 
> Standing on weaker ground is precisely what FSF wants to avoid at all
> costs.
> 
> Jambunathan K.

This discussion is now considered off-topic for this list.
Please take it elsewhere.

- Carsten

Re: New maintainer

[Jambunathan K]

> Just trying to reconcile my understanding of your situation with how
> you write about it.

This post (not by me) summarizes my position well.

        http://lists.gnu.org/archive/html/emacs-devel/2013-04/msg00096.html

I have also criticized FSF's arbitrary handling of my request here.

        http://lwn.net/Articles/547737/

If you move over to emacs-devel, you will see some of the commenters
there are very guarded in their response.  It will only go on to show
that I raise valid questions.

People who have flamed me cannot differentiate between oranges and
lemons.  It is not their work that is at stake.  So they can just call
me a troll and dismiss the broader questions I am raising.

Jambunathan K.

Re: New maintainer

[Glyn Millington]

Bastien <bzg@gnu.org> writes:

> I'm stepping down as the Org maintainer.
>
> Carsten accepted to step up, if the community agrees.  Please raise
> your thumbs up or your concerns, if any.
>
> I'm glad I had this opportunity to work as "Robin" and I'm even more
> glad "Batman" may strike back!

A huge thumbs up from this extremely grateful user!

And an equally huge thank you, Bastien, for shouldering the burden of
maintainership, for the diligence with which you have handled the task
(and the hundreds/thousands of emails which have kept the project moving)
and maybe above all for your patience and steadfastness under totally
unmerited fire. 

with all good wishes





Glyn

Re: New maintainer

[Aaron Ecay]

Hi Bastien,

2013ko apirilak 18an, Bastien-ek idatzi zuen:

[...]

> I'm glad I had this opportunity to work as "Robin" and
> I'm even more glad "Batman" may strike back!

Just as Batman and Robin are often seen together, I hope you’ll continue
to be a presence in the org community.  I always appreciate the
helpfulness and patience that you embody.

Thanks,

-- 
Aaron Ecay

Re: New maintainer

[Rasmus]

Bastien <bzg@gnu.org> writes:

> I'm stepping down as the Org maintainer.
>
> Carsten accepted to step up, if the community agrees.
> Please raise your thumbs up or your concerns, if any.
>
> I'm glad I had this opportunity to work as "Robin" and
> I'm even more glad "Batman" may strike back!

Thanks for your hard work, Bastien.  Great with release 8.0!

I expect you will still be around the mailing list, no?

–Rasmus

-- 
This is the kind of tedious nonsense up with which I will not put

Re: New maintainer

[Bastien]

Rasmus <rasmus@gmx.us> writes:

> I expect you will still be around the mailing list, no?

I'll focus on something else, but I'll stick around for sure,
at least to ask questions and report bugs!

-- 
 Bastien

Re: New maintainer

[Detlef Steuer]

The king is dead, long live the king!
:-)

Thank you, Bastien, for all the work!

And thank you, Carsten, for all the work to come! 

Detlef


On Thu, 18 Apr 2013 18:53:32 +0200
Bastien <bzg@gnu.org> wrote:

> Dear all,
> 
> I'm stepping down as the Org maintainer.
> 
> Carsten accepted to step up, if the community agrees.
> Please raise your thumbs up or your concerns, if any.
> 
> I'm glad I had this opportunity to work as "Robin" and
> I'm even more glad "Batman" may strike back!
> 
> :)
> 
> -- 
>  Bastien
> 
> 
> 

Re: New maintainer

[François Pinard]

Bastien <bzg@gnu.org> writes:

> Please raise your thumbs up or your concerns, if any.

Bastien, your maintainership has been just outstanding, so far that I
could judge.  You're among the great maintainers I happened to meet, and
I tremendously enjoyed your way of driving the project.  Let me thank
you for it all.

I wish Carsten will get, from all of us — OK! given a proper email kill
file :-) — the same level of good will, enthusiasm and collaboration we
have seen on this user group all along for the recent year.

François

Re: New maintainer

[Alan Schmitt]

Bastien writes:

> Carsten accepted to step up, if the community agrees.
> Please raise your thumbs up or your concerns, if any.

Thumbs up! And thank you so much for what you did.

Alan

Re: New maintainer

[Thomas S. Dye]

Aloha Bastien,

Bastien <bzg@gnu.org> writes:

> Dear all,
>
> I'm stepping down as the Org maintainer.

Thank you for your excellent work as maintainer.  I'm pleased to have
had the opportunity to work with you.

>
> Carsten accepted to step up, if the community agrees.
> Please raise your thumbs up or your concerns, if any.
>

Yes, thumbs up.

> I'm glad I had this opportunity to work as "Robin" and
> I'm even more glad "Batman" may strike back!

You should be proud that you're giving back a much improved piece of
software.  From my point of view, the new exporter framework is a huge
step forward.  Congratulations!

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: New maintainer

[Bastien]

Hi Thomas,

tsd@tsdye.com (Thomas S. Dye) writes:

> Thank you for your excellent work as maintainer.  I'm pleased to have
> had the opportunity to work with you.

Having you improve the documentation while Nicolas and I were hard
working on it was a great relief, thanks again for that.

> You should be proud that you're giving back a much improved piece of
> software.  From my point of view, the new exporter framework is a huge
> step forward.  Congratulations!

Yes -- I second Carsten's surprise that someone was crazy enough to
undertake this enormous work.  And its potential still waits to be
completely unfold! 

-- 
 Bastien

Re: New maintainer

[Jonathan Leech-Pepin]

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

Hello Bastien,


On 18 April 2013 12:53, Bastien <bzg@gnu.org> wrote:

> Dear all,
>
> I'm stepping down as the Org maintainer.
>

Thank you for all the work you've done.

>
> Carsten accepted to step up, if the community agrees.
> Please raise your thumbs up or your concerns, if any.
>
> Thumbs up from me as well.


> I'm glad I had this opportunity to work as "Robin" and
> I'm even more glad "Batman" may strike back!
>
> :)
>
> --
>  Bastien
>
> --
Jon

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

Re: New maintainer

[Tom Davey]

Hi everybody,

I'm just an Org user, one of the many anonymous persons who have
benefited from this fantastic piece of software. Over the past two
years I have come to use Org every day, all day long, more than any
other application with the possible exception of a Web browser. It's
hard to overestimate the value I receive from Org, the sheer personal
effectiveness I've gained.

Bastien, a thousand thanks for your work as maintainer. Thanks as well
to all the other skillful and creative programmers on this list who
make org continually more powerful and astonishing. Especial thanks to
Carsten, both for the past and now in advance as the new maintainer.

With grateful regards to all,
Tom Davey

--
Tom Davey
tom@tomdavey.com
New York NY USA

Re: New maintainer

[Ian Barton]

On 18/04/13 22:52, Tom Davey wrote:
> Hi everybody,
>
> I'm just an Org user, one of the many anonymous persons who have
> benefited from this fantastic piece of software. Over the past two
> years I have come to use Org every day, all day long, more than any
> other application with the possible exception of a Web browser. It's
> hard to overestimate the value I receive from Org, the sheer personal
> effectiveness I've gained.
>
> Bastien, a thousand thanks for your work as maintainer. Thanks as well
> to all the other skillful and creative programmers on this list who
> make org continually more powerful and astonishing. Especial thanks to
> Carsten, both for the past and now in advance as the new maintainer.
>
> With grateful regards to all,
> Tom Davey

Me too:) Many thanks to Bastien for all his hard work and for patiently 
answering questions and fixing bugs. Also welcome back to Carsten!

Best wishes,

Ian.

Re: New maintainer

[Charles Berry]

Bastien <bzg <at> gnu.org> writes:

> 
> Dear all,
> 
> I'm stepping down as the Org maintainer.
> 

You have done an awesome job. 

This is still the "friendliest little town" on the internet thanks to 
your patience and good judgment in no small part.

And 8.0 is a fine product.


> Carsten accepted to step up, if the community agrees.
> Please raise your thumbs up or your concerns, if any.
> 

+2 thumbs

Gmane requires me to type the capcha 'uplift' to send this message.
How appropriate!

All the Best,

Re: New maintainer

[Suvayu Ali]

On Fri, Apr 19, 2013 at 12:24:46AM +0000, Charles Berry wrote:
> Bastien <bzg <at> gnu.org> writes:
> 
> > Dear all,
> > 
> > I'm stepping down as the Org maintainer.
> 
> You have done an awesome job. 
> 
> This is still the "friendliest little town" on the internet thanks to 
> your patience and good judgment in no small part.

Indeed!  Thanks a lot :).  And welcome back Carsten.

:)

-- 
Suvayu

Open source is the future. It sets us free.

Re: New maintainer

[Bernt Hansen]

Bastien <bzg@gnu.org> writes:

> Dear all,
>
> I'm stepping down as the Org maintainer.
>
> Carsten accepted to step up, if the community agrees.
> Please raise your thumbs up or your concerns, if any.
>
> I'm glad I had this opportunity to work as "Robin" and
> I'm even more glad "Batman" may strike back!
>
> :)


Dear Bastien and Carsten,

Thanks, Bastien, for doing an awesome job as the org-mode maintainer
these past few years.  You had a huge job filling Carsten's shoes and
you did an excellent job.  I really appreciate all of the work you have
done as our org-mode maintainer and hope you will continue to contribute
in the future.

Welcome back Carsten!  Please let us know how we can help make your job
easier.  None of us have infinite time to devote to this excellent
project but I'm sure we can help lessen the burden that maintaining this
beast must be.  I use this awesome tool everyday and really appreciate
the thought and effort put into making org-mode the fabulous tool that
it is.

/me can't draw two thumbs up in Ascii without making it look obscene ;)

Warmest regards,
Bernt

Re: New maintainer

[Yagnesh Raghava Yakkala]

Hello Bastien,

Thanks a lot for the great work so far. You are the best.

On Apr 19 2013, Bastien <bzg@gnu.org> wrote:

> Dear all,
>
> I'm stepping down as the Org maintainer.
>
> Carsten accepted to step up, if the community agrees.
> Please raise your thumbs up or your concerns, if any.

👍

>
> I'm glad I had this opportunity to work as "Robin" and
> I'm even more glad "Batman" may strike back!
>
> :)


Thanks.,
--
ఎందరో మహానుభావులు అందరికి వందనములు.
YYR

Re: New maintainer

[Noorul Islam Kamal Malmiyoda]

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

Bastien,

I use org-mode every day and it is really great to see that this project is
always growing. You did an excellent job taking this to 8.0.

Carsten,

Welcome back and looking forward to 8.x

Thanks and Regards
Noorul


On Thu, Apr 18, 2013 at 10:23 PM, Bastien <bzg@gnu.org> wrote:

> Dear all,
>
> I'm stepping down as the Org maintainer.
>
> Carsten accepted to step up, if the community agrees.
> Please raise your thumbs up or your concerns, if any.
>
> I'm glad I had this opportunity to work as "Robin" and
> I'm even more glad "Batman" may strike back!
>
> :)
>
> --
>  Bastien
>
>
>

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

Re: New maintainer

[Robert Klein]

Hi Bastien,

thank you very very much for maintaining org-mode
for the last two years.

You did a great job maintaining org-mode and keeping
its community together.

I agree with everything Carsten says in his mail
"Changing the maintainer".

While I am happy it is Carsten of all people who
takes up the maintainership, at the same time I'm
very sorry you are stepping down.


Best regards
Robert



On 04/18/2013 06:53 PM, Bastien wrote:
> Dear all,
> 
> I'm stepping down as the Org maintainer.
> 
> Carsten accepted to step up, if the community agrees.
> Please raise your thumbs up or your concerns, if any.
> 
> I'm glad I had this opportunity to work as "Robin" and
> I'm even more glad "Batman" may strike back!
> 
> :)
> 


-- 
Robert Klein - Max Planck-Institut für Polymerforschung
Ackermannweg 10
55128 Mainz

Re: New maintainer

[Christian Moe]

Bastien,

What the others said... Thanks for all your work! It's been a pleasure to
follow Org-mode.

Yours,
Christian

Bastien writes:

> Dear all,
>
> I'm stepping down as the Org maintainer.
>
> Carsten accepted to step up, if the community agrees.
> Please raise your thumbs up or your concerns, if any.
>
> I'm glad I had this opportunity to work as "Robin" and
> I'm even more glad "Batman" may strike back!
>
> :)

Thank you very much Bastien! Hello Carsten! (was: New maintainer)

[Karl Voit]

* Bastien <bzg@gnu.org> wrote:
> Dear all,

Dear Bastien,

> I'm stepping down as the Org maintainer.

I am sorry to have to read this.

As I entered this universe of great Personal Information Management
LEGO bricks two years ago, you were the maintainer in charge of this
huge project. 

Although I already had been part of several communities, I was
overwhelmed by the warm welcome in this one. I loved to enter it, I
love to stay in it.

You are very patient with Org-mode/ELISP rookies and you are
incredible cautious and diplomatic with I-do-not-know-how-to-
describe-but-you-know-who-I-mean people. I learned a *lot* from you
here on this mailing list, not only related to software.

Despite the fact that I am not able to add (ELISP-)code (yet) you
still give me the feeling that my contributions are an important
part of this community and this is just great.

I thank you for all your effort of the past years and do hope that
you will be an important part of this project in future as well.

Je t'embrasse, merci beaucoup!

> Carsten accepted to step up, if the community agrees.
> Please raise your thumbs up or your concerns, if any.

When I first read the subject, I was shocked. Especially because of
this silly I-want-to-take-over-and-become-maintainer-discussion of
the past weeks.  

But with Carsten mentioned, I am relieved :-)

My thumbs are up in the air for sure. I am glad that Carsten is
willing to take over again. I can imagine what this means and it is
not easy to find someone who is competent *and* is willing to spend
his/her time on such a project.

Welcome Carsten, I thank you in advance and wish you all the best
for this job!

> I'm glad I had this opportunity to work as "Robin" and
> I'm even more glad "Batman" may strike back!

Nice picture. Is someone able to photoshop this with their heads for
the web page announcement? :-)


PS: Tomorrow, I give an Org-mode talk [1] at the Linuxdays Graz
(Austria) and I am eager to announce all the changes of the past
days (version 8, best toolset ever, new maintainer) to the audience.
 

  1. http://glt13-programm.linuxtage.at/events/161.de.html (German)
-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
       > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github

Re: New maintainer

[Thorsten Jolitz]

Bastien <bzg@gnu.org> writes:

> I'm stepping down as the Org maintainer.

Thats bad news, managing Org-mode appears like such a huge task, and I
always wondered how you were able to deal with all those mails and
patches and bugs with such efficiency, and detailled knowledge about all
those unnumerable features of Org-mode. 

> Carsten accepted to step up

Luckily the good news are attached to the bad news. 

-- 
cheers,
Thorsten

Re: New maintainer

[Sean O'Halpin]

Hi Bastien,

I'd like to thank you for the fabulous job you've done as maintainer.

Best wishes,
Sean

On Thu, Apr 18, 2013 at 5:53 PM, Bastien <bzg@gnu.org> wrote:
> Dear all,
>
> I'm stepping down as the Org maintainer.
>
> Carsten accepted to step up, if the community agrees.
> Please raise your thumbs up or your concerns, if any.
>
> I'm glad I had this opportunity to work as "Robin" and
> I'm even more glad "Batman" may strike back!
>
> :)
>
> --
>  Bastien
>
>

Re: New maintainer

[Charles Philip Chan]

Bastien <bzg@gnu.org> wrote:

Hi Bastien,

>I'm stepping down as the Org maintainer.

Thank you for all the hard work you have done in maintaining Org-mode.

>Carsten accepted to step up, if the community agrees.
>Please raise your thumbs up or your concerns, if any.

+1

Charles


--
Sent from Kaiten Mail. Please excuse my brevity.

Re: New maintainer

[Adolfo Benedetti]

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

Hi Bastien,

Thank you for your hard work and efforts as org-mode-maintainer,

>Carsten accepted to step up, if the community agrees.

nice, thank you Carsten!


cheers

--
Adolfo Benedetti
M +31 614 706 176


2013/4/19 Charles Philip Chan <cpchan@bell.net>

> Bastien <bzg@gnu.org> wrote:
>
> Hi Bastien,
>
> >I'm stepping down as the Org maintainer.
>
> Thank you for all the hard work you have done in maintaining Org-mode.
>
> >Carsten accepted to step up, if the community agrees.
> >Please raise your thumbs up or your concerns, if any.
>
> +1
>
> Charles
>
>
> --
> Sent from Kaiten Mail. Please excuse my brevity.
>
>

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

Re: New maintainer

[Rainer Stengele]

Am 18.04.2013 18:53, schrieb Bastien:
> Dear all,
> 
> I'm stepping down as the Org maintainer.
> 
> Carsten accepted to step up, if the community agrees.
> Please raise your thumbs up or your concerns, if any.
> 
> I'm glad I had this opportunity to work as "Robin" and
> I'm even more glad "Batman" may strike back!
> 
> :)
> 
Bastien,

let me also thank you so much for your great work and patience answering so many questions!
A lot of questions and ideas I had you simply answered by coding the solution - awesome!
I think you did a very good job and I hope you will stay in the newsgroup in the future.

Carsten, welcome back!

Rainer

Re: New maintainer

[Russell Adams]

On Thu, Apr 18, 2013 at 06:53:32PM +0200, Bastien wrote:
> Dear all,
>
> I'm stepping down as the Org maintainer.
>
> Carsten accepted to step up, if the community agrees.
> Please raise your thumbs up or your concerns, if any.
>
> I'm glad I had this opportunity to work as "Robin" and
> I'm even more glad "Batman" may strike back!

Bastien,

You've done an excellent job. Your patience has been incredible, and
Org has prospered. Take a break, you deserve it!

8.0 looks amazing, and I'm excited to see what the community has
created. Org certainly has the benefit of many talented coders.

Thanks!

------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: New maintainer

[Christopher Allan Webber]

You've done great work Bastien!

And I look forward to Batman Returns!

Bastien writes:

> Dear all,
>
> I'm stepping down as the Org maintainer.
>
> Carsten accepted to step up, if the community agrees.
> Please raise your thumbs up or your concerns, if any.
>
> I'm glad I had this opportunity to work as "Robin" and
> I'm even more glad "Batman" may strike back!
>
> :)

Fwd: New maintainer

[Gary Oberbrunner]

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

[I still can't learn to reply-all to these. :-( ]

---------- Forwarded message ----------
From: Gary Oberbrunner <garyo@oberbrunner.com>
Date: Fri, Apr 19, 2013 at 9:02 PM
Subject: Re: [O] New maintainer
To: Christopher Allan Webber <cwebber@dustycloud.org>


Thanks for the great work, Bastien!  Carsten, you have big shoes to fill
but we all have confidence.  Thanks!  As an open-source maintainer myself I
know how much night-and-weekend work goes into it.


On Fri, Apr 19, 2013 at 12:04 PM, Christopher Allan Webber <
cwebber@dustycloud.org> wrote:

> You've done great work Bastien!
>
> And I look forward to Batman Returns!
>
> Bastien writes:
>
> > Dear all,
> >
> > I'm stepping down as the Org maintainer.
> >
> > Carsten accepted to step up, if the community agrees.
> > Please raise your thumbs up or your concerns, if any.
> >
> > I'm glad I had this opportunity to work as "Robin" and
> > I'm even more glad "Batman" may strike back!
> >
> > :)
>
>
>


-- 
Gary



-- 
Gary

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

Re: New maintainer

[T.F. Torrey]

Thank you for your hard work, Bastien. You've done a fantastic job
under unusually adversarial conditions.

On Thu, Apr 18, 2013 at 9:53 AM, Bastien <bzg@gnu.org> wrote:
> Dear all,
>
> I'm stepping down as the Org maintainer.
>
> Carsten accepted to step up, if the community agrees.
> Please raise your thumbs up or your concerns, if any.
>
> I'm glad I had this opportunity to work as "Robin" and
> I'm even more glad "Batman" may strike back!
>
> :)
>
> --
>  Bastien
>
>

Re: New maintainer

[Eric Abrahamsen]

Bastien <bzg@gnu.org> writes:

> Dear all,
>
> I'm stepping down as the Org maintainer.
>
> Carsten accepted to step up, if the community agrees.
> Please raise your thumbs up or your concerns, if any.
>
> I'm glad I had this opportunity to work as "Robin" and
> I'm even more glad "Batman" may strike back!
>
> :)

Hats off, Bastien, it was deftly done.

It's also been a pleasure to witness the surprisingly successful
marriage of two different coding styles: Bastien's damn-the-torpedoes
patch-the-SOB-and-get-it-out-the-door approach, matched with Nicolas'
return to first principles: structure and cleanliness. I'm quite
convinced that the two approaches have been equally essential to Org
mode's current success (and advance apologies for any perceived
mischaracterizations!).

I'm one of the post-Carsten young'uns, but I can't imagine we'll have
any complaints with the man who started it all...

Eric

Re: New maintainer

[Bastien]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> It's also been a pleasure to witness the surprisingly successful
> marriage of two different coding styles: Bastien's damn-the-torpedoes
> patch-the-SOB-and-get-it-out-the-door approach, matched with Nicolas'
> return to first principles: structure and cleanliness. I'm quite
> convinced that the two approaches have been equally essential to Org
> mode's current success (and advance apologies for any perceived
> mischaracterizations!).

Yeah.

Let me quote Jamie Zawinski's interview from "Coders at work":

  Zawinski: [...] It's great to rewrite your code and make it cleaner
  and by the third time it'll actually be pretty.  But that's not the
  point---you're not here to write code, you're here to ship products.
  
  Seibel: Folks engaged in overengineering usually say, "Well, once
  I've got this framework in place everything will be easy after that.
  So I'll actually save time by doing this.
  
  Zawinski: That is always the theory.

  Seibel: And there are times when that theory is true, when someone
  has good sense and the framework isn't too elaborate, and it does
  save time.

I actually agree with both points of view, especially with the last
sentence.  And it's easy to play jwz when you can trust someone for
playing the other role :)

-- 
 Bastien

Re: New maintainer

[Eric Abrahamsen]

Bastien <bzg@gnu.org> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> It's also been a pleasure to witness the surprisingly successful
>> marriage of two different coding styles: Bastien's damn-the-torpedoes
>> patch-the-SOB-and-get-it-out-the-door approach, matched with Nicolas'
>> return to first principles: structure and cleanliness. I'm quite
>> convinced that the two approaches have been equally essential to Org
>> mode's current success (and advance apologies for any perceived
>> mischaracterizations!).
>
> Yeah.
>
> Let me quote Jamie Zawinski's interview from "Coders at work":
>
>   Zawinski: [...] It's great to rewrite your code and make it cleaner
>   and by the third time it'll actually be pretty.  But that's not the
>   point---you're not here to write code, you're here to ship products.
>   
>   Seibel: Folks engaged in overengineering usually say, "Well, once
>   I've got this framework in place everything will be easy after that.
>   So I'll actually save time by doing this.
>   
>   Zawinski: That is always the theory.
>
>   Seibel: And there are times when that theory is true, when someone
>   has good sense and the framework isn't too elaborate, and it does
>   save time.
>
> I actually agree with both points of view, especially with the last
> sentence.  And it's easy to play jwz when you can trust someone for
> playing the other role :)

And, without re-opening any tedious discussions that we've already put
behind us, it's generally the person playing the jwz role who ends up as
"maintainer" -- and that's probably as it should be.

Re: New maintainer

[Andreas Röhler]

Am 18.04.2013 18:53, schrieb Bastien:
> Dear all,
>
> I'm stepping down as the Org maintainer.
>
> Carsten accepted to step up, if the community agrees.
> Please raise your thumbs up or your concerns, if any.
>
> I'm glad I had this opportunity to work as "Robin" and
> I'm even more glad "Batman" may strike back!
>
> :)
>

Hi Bastien,

have been afk for some days, please let me close up to all thanks seen here.
What's have been quite impressive already was the pure amount of mailings, you delt with day by day.

Having seen you working that hard also raises some concern for now: that daily galeere must be costly: whoever undertakes it, will pay a price. It's your honor having payed 
it for all of us. So far can't consider this stepping down anything else as a loss for org-mode.

While ignoring circumstances of your resign, it's no secret, some unpleasant events happended last weeks, made your task more burdensome as necessary.
I'm not speaking of possible errors - everyone who works will make errors. Who works outstanding might make outstanding errors.
Purely abstractly spoken(!)

OTHO the very best mind a team has --i.e. Carsten--, should not take the most burdensome tasks. IMHO Carsten should be spared for strategic decisions, define and decide the 
path of further development.

In case you didn't lose your interest and just that recent unpleasant experiences caused your resign, what about staying maintainer backed by all this confidence revealed 
beside of some new experience?

Also maintainer must not mean being strictly a single person, even if languages grammar doesn't foresee otherwise.
Regarding recent difficulties, probably it's wise, if Carsten has a closer look, decides in cases from time to time.
IIUC Emacs itself was driven in a similar way last years more or less outspoken - consider this part of it's success story.

Best regards,

Andreas

Re: New maintainer

[Bastien]

Hi Andreas,

thanks for the kind words.

The decision to step down after 8.0 was taken a long time ago,
before the recent problems on the list.  I had to find someone
willing to step in before I could announce this.

I agree "maintainer" is not necessary a single person: my main
purpose was to build a team, so that future maintainer(s) would
feel okay to act as you suggest, for strategic decisions rather
than everyday ground-level stuff.

This position is easy to describe but difficult to hold, because
it depends so much on the community.

This *is* the real challenge I see now: that each of us endorses
some kind of responsability, some co-maintainership feeling, and
act as constructively as possible---be it for org-mode, worg, the
website or whatever.

I already can feel some go in this direction and that's great :)

-- 
 Bastien

Re: New maintainer

[Andreas Röhler]

Hi Bastien,

Am 22.04.2013 00:39, schrieb Bastien:
> Hi Andreas,
>
> thanks for the kind words.
>
> The decision to step down after 8.0 was taken a long time ago,
> before the recent problems on the list.  I had to find someone
> willing to step in before I could announce this.
>

Okay, a good news in circumstances.

> I agree "maintainer" is not necessary a single person: my main
> purpose was to build a team, so that future maintainer(s) would
> feel okay to act as you suggest, for strategic decisions rather
> than everyday ground-level stuff.
>
> This position is easy to describe but difficult to hold,

Precisely.

> because it depends so much on the community.
>
> This *is* the real challenge I see now: that each of us endorses
> some kind of responsability, some co-maintainership feeling, and
> act as constructively as possible---be it for org-mode, worg, the
> website or whatever.
>
> I already can feel some go in this direction and that's great :)
>

Indeed.

Nonetheless, WRT the amount of traffic IMHO having someone to range things a little bit before Carsten must tell will be a great advantage.

Thanks all proving that great stuff,

Andreas

Re: New maintainer

[AG]

Bastien <bzg <at> gnu.org> writes:

> 
> Dear all,
> 
> I'm stepping down as the Org maintainer.
> 
> Carsten accepted to step up, if the community agrees.
> Please raise your thumbs up or your concerns, if any.
> 
> I'm glad I had this opportunity to work as "Robin" and
> I'm even more glad "Batman" may strike back!
> 
> :)
> 


Dear Bastien,
 I too would like to express my thanks for all your hard work in keeping
org running smoothly over the last couple of years, and unfailing
(preternatural) graciousness even in the face of personal and unprofessional
attacks. I hope you are leaving of your own volition. Illegitimi non
carborundum.


I am also grateful to Carsten for his great contributions of Org, reftex and
cdlatex, and happy to hear he will be taking over.

AG

Re: New maintainer

[Julian M. Burgos]

I echo all the thanks that other people already gave.  My digital life
orbits around org-mode, so thanks to everyone who contributed to this
project.  Keep it up!!

Julian  

-- 
Julian Mariano Burgos, PhD
Hafrannsóknastofnunin/Marine Research Institute
Skúlagata 4, 121 Reykjavík, Iceland
Sími/Telephone : +354-5752037
Bréfsími/Telefax:  +354-5752001
Netfang/Email: julian@hafro.is


Bastien writes:

> Dear all,
>
> I'm stepping down as the Org maintainer.
>
> Carsten accepted to step up, if the community agrees.
> Please raise your thumbs up or your concerns, if any.
>
> I'm glad I had this opportunity to work as "Robin" and
> I'm even more glad "Batman" may strike back!
>
> :)

Re: New maintainer

[Jay Kerns]

On Mon, Apr 22, 2013 at 6:27 AM, Julian M. Burgos <julian@hafro.is> wrote:
> I echo all the thanks that other people already gave.  My digital life
> orbits around org-mode, so thanks to everyone who contributed to this
> project.  Keep it up!!
>
> Julian
>

I have been watching these multiple messages go by trying to find a
space to get a word in edgewise, but instead of waiting longer let me
just say now:  I am sorry to see you step down, Bastien, but also, I
am happy about your bright future ahead.  Congratulations! on a job
very well done!

Regards,

-- 
Jay

Re: New maintainer

[Matt Price]

Just echoing what everyone else has said:  Bastien, your tenure at the
helm has just been fabulous.  8.0 is just an amazing release and org
already just amazingly great has become even better.  Carsten, it's so
generous for you to come back to this project to which you have
already devoted so much energy.  No other tool I use has had such a
great pair of lead developers or such an open and helpful community.
thank you both!

Matt

Re: New maintainer

[Jason Dunsmore]

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

Thanks for all of your hard work on org-mode Bastien!  Watching you in
action has taught me a great deal about good project/community leadership.
 If there's anything I can do to help with the transition, please let me
know.

Regards,
Jason

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

New maintainer

[Stefan Monnier]

So, now that I stepped down, we need to find a new maintainer (or a new
maintainer-team).

Don't be afraid: it's a fun job.  Oldtimers take care of a lot of the
work, and it's not like you need to know everything about Emacs's
internals or anything (e.g. after all these years, the redisplay code is
still very much foreign to me).

My experience co-maintaining with Yidong was very good, so I'd
recommend that.

Of course, we'd also welcome people volunteering to take charge of
particular sub-tasks, so as to reduce the overall load of the
maintainer.  E.g. taking care of GNU ELPA.

But we still need a head maintainer, whose task is mostly to keep an eye
on the general direction, can make a final decision when we can't reach
an agreement (of course, we could also delegate that task to
/dev/random), and to be the official contact point with the FSF.

If you're still not sue the job is for you, think about all the side
benefits, such as the fact that you can get as many copies of Emacs as
you want *for free*, and you even get ssh access to fencepost.gnu.org!


        Stefan "I'm not in emacs-devel right now, so keep m in the Cc"

Re: New maintainer

[Nicolas Petton]

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

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

> So, now that I stepped down, we need to find a new maintainer (or a new
> maintainer-team).
>
> Don't be afraid: it's a fun job.  Oldtimers take care of a lot of the
> work, and it's not like you need to know everything about Emacs's
> internals or anything (e.g. after all these years, the redisplay code is
> still very much foreign to me).
>
> My experience co-maintaining with Yidong was very good, so I'd
> recommend that.
>
> Of course, we'd also welcome people volunteering to take charge of
> particular sub-tasks, so as to reduce the overall load of the
> maintainer.  E.g. taking care of GNU ELPA.

Hi Stefan,

As I told you, I would gladly volunteer, but:

- I would only have ~6 hours per week to dedicate to Emacs, which seems
  to be too little considering the task.
- Many parts of the codebase are completely foreign to me (including
  most of the C code).
- Being relatively new, I probably don't have enough experience with the
  community.

That said, I would like to give a hand to the new maintainer(s), so working
on some sub-tasks would be a good fit I think.

Cheers,
Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: New maintainer

[John Wiegley]

>>>>> Nicolas Petton <nicolas@petton.fr> writes:

> - I would only have ~6 hours per week to dedicate to Emacs, which seems to
> be too little considering the task.

Stefan, can you briefly describe what the time commitments would be for anyone
seeking to become am maintainer?  6 hours a week would also be a bit much for
me as well, so perhaps a little more clarification would be helpful.

John

Re: New maintainer

[Eli Zaretskii]

> From: Nicolas Petton <nicolas@petton.fr>
> Date: Tue, 29 Sep 2015 17:26:11 +0200
> 
> That said, I would like to give a hand to the new maintainer(s), so working
> on some sub-tasks would be a good fit I think.

One task that I think needs attention from as many people as possible
is reviewing the patches and working on bug reports, in the areas
where you consider yourself knowledgeable enough.

TIA

Re: New maintainer

[Aurélien Aptel]

On Thu, Oct 1, 2015 at 8:27 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Nicolas Petton <nicolas@petton.fr>
>> Date: Tue, 29 Sep 2015 17:26:11 +0200
>>
>> That said, I would like to give a hand to the new maintainer(s), so working
>> on some sub-tasks would be a good fit I think.
>
> One task that I think needs attention from as many people as possible
> is reviewing the patches and working on bug reports, in the areas
> where you consider yourself knowledgeable enough.

Like Stefan, I think the debbugs UI could be improved. I really hate
browsing it, I get lost in all the listing, and don't know which bugs
are important.

Re: New maintainer

[Eli Zaretskii]

> Date: Thu, 1 Oct 2015 16:13:31 +0200
> From: Aurélien Aptel <aurelien.aptel+emacs@gmail.com>
> Cc: Nicolas Petton <nicolas@petton.fr>, Stefan Monnier <monnier@iro.umontreal.ca>, 
> 	Emacs development discussions <emacs-devel@gnu.org>
> 
> > One task that I think needs attention from as many people as possible
> > is reviewing the patches and working on bug reports, in the areas
> > where you consider yourself knowledgeable enough.
> 
> Like Stefan, I think the debbugs UI could be improved. I really hate
> browsing it, I get lost in all the listing, and don't know which bugs
> are important.

There's a debbugs package in ELPA, did you try it?

Re: New maintainer

[Dmitry Gutov]

On 10/01/2015 05:13 PM, Aurélien Aptel wrote:

> Like Stefan, I think the debbugs UI could be improved. I really hate
> browsing it, I get lost in all the listing, and don't know which bugs
> are important.

That might be one of the tasks for the new maintainer (or alternatively, 
finding the person willing to do that job).

FWIW, I think almost anything would be better than Debbugs (Bugzilla, 
for instance). But I don't have enough spare time to work on a 
replacement in the near future.

Re: New maintainer

[John Wiegley]

>>>>> Dmitry Gutov <dgutov@yandex.ru> writes:

> FWIW, I think almost anything would be better than Debbugs (Bugzilla, for
> instance). But I don't have enough spare time to work on a replacement in
> the near future.

The only reason I like Bugzilla (which I use for Ledger) is due to the Java UI
Deskzilla, which is freely available for those working on Open Source
projects. It makes working with Bugzilla quick, and working offline is quite
well-done.

Other than that, I've actively used GitHub, Redmine and Trac, and out of all
those, perhaps GitHub is the easiest to work with, despite having the smallest
feature set.

John

Re: New maintainer

[Dmitry Gutov]

On 10/01/2015 09:35 PM, John Wiegley wrote:

> The only reason I like Bugzilla (which I use for Ledger) is due to the Java UI
> Deskzilla, which is freely available for those working on Open Source
> projects. It makes working with Bugzilla quick, and working offline is quite
> well-done.

Last time the discussion of bug trackers came up, certain people stated 
a strong preference for bug trackers that have an Emacs interface (like 
the debbugs package in ELPA). And AFAIK RMS always required that the bug 
tracker could be used entirely over email.

> Other than that, I've actively used GitHub, Redmine and Trac, and out of all
> those, perhaps GitHub is the easiest to work with, despite having the smallest
> feature set.

Yup. It also will never be an option for Emacs.

Though one might look into using GitLab, to be hosted at FSF premises.

Re: New maintainer

[John Wiegley]

>>>>> Dmitry Gutov <dgutov@yandex.ru> writes:

>> The only reason I like Bugzilla (which I use for Ledger) is due to the Java
>> UI Deskzilla, which is freely available for those working on Open Source
>> projects. It makes working with Bugzilla quick, and working offline is
>> quite well-done.

> Last time the discussion of bug trackers came up, certain people stated a
> strong preference for bug trackers that have an Emacs interface (like the
> debbugs package in ELPA). And AFAIK RMS always required that the bug tracker
> could be used entirely over email.

I can understand that.

>> Other than that, I've actively used GitHub, Redmine and Trac, and out of
>> all those, perhaps GitHub is the easiest to work with, despite having the
>> smallest feature set.

> Yup. It also will never be an option for Emacs.

Yeah, I'll be surprised if they continue to be around as long as Emacs will be
anyway. :)

John

Re: New maintainer

[Barry Warsaw]

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

On Oct 01, 2015, at 10:18 PM, Dmitry Gutov wrote:

>Last time the discussion of bug trackers came up, certain people stated a
>strong preference for bug trackers that have an Emacs interface (like the
>debbugs package in ELPA). And AFAIK RMS always required that the bug tracker
>could be used entirely over email.

There's also Roundup which is used by the Python project.  It's very email
friendly and has a good web ui too.

http://roundup-tracker.org/

Cheers,
-Barry

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: New maintainer

[Dmitry Gutov]

Hi Barry,

On 10/06/2015 02:37 AM, Barry Warsaw wrote:

> There's also Roundup which is used by the Python project.  It's very email
> friendly and has a good web ui too.
>
> http://roundup-tracker.org/

The feature list seems to check all the boxes, although the web ui seems 
a bit bare-bones in terms of looks, compared to certain other options.

But even so, control over email makes it a serious contender. Not sure 
what are the next steps (guess it's up to the new maintainer(s)), but 
deploying it somewhere we all could take a look would be a good choice. 
Next steps would be doing the same for a few other alternatives, 
creating a migration script, and an Emacs interface for it (probably by 
forking the debbugs package).

Re: New maintainer

[Stefan Monnier]

> FWIW, I think almost anything would be better than Debbugs (Bugzilla, for
> instance).

The grass is always greener on the other side.


        Stefan

Re: New maintainer

[Przemysław Wojnowski]

Maybe it would be a good time to consider creating a Roadmap with vision of
Emacs future and Product Backlog that would prioritize things?

It's just a thought for consideration. I'm not in a position to tell others
what to do.

Cheers,
Przemysław

W dniu 29.09.2015 o 08:28, Stefan Monnier pisze:
> So, now that I stepped down, we need to find a new maintainer (or a new
> maintainer-team).
>
> Don't be afraid: it's a fun job.  Oldtimers take care of a lot of the
> work, and it's not like you need to know everything about Emacs's
> internals or anything (e.g. after all these years, the redisplay code is
> still very much foreign to me).
>
> My experience co-maintaining with Yidong was very good, so I'd
> recommend that.
>
> Of course, we'd also welcome people volunteering to take charge of
> particular sub-tasks, so as to reduce the overall load of the
> maintainer.  E.g. taking care of GNU ELPA.
>
> But we still need a head maintainer, whose task is mostly to keep an eye
> on the general direction, can make a final decision when we can't reach
> an agreement (of course, we could also delegate that task to
> /dev/random), and to be the official contact point with the FSF.
>
> If you're still not sue the job is for you, think about all the side
> benefits, such as the fact that you can get as many copies of Emacs as
> you want *for free*, and you even get ssh access to fencepost.gnu.org!
>
>
>          Stefan "I'm not in emacs-devel right now, so keep m in the Cc"
>

Re: New maintainer

[John Wiegley]

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

> So, now that I stepped down, we need to find a new maintainer (or a new
> maintainer-team).

I'd like to self-nominate for that role, Stefan. I've been contributing to
Emacs since 1994, and have loved it all the while. Emacs Lisp remains a very
enjoyable language to write certain types of code in.

Some things I'd like to see happen to Emacs are more efficiency, closing bugs,
and wider adoption of some of our newest features, like lexical scoping. That
said, I'm also excited by new prospects, and wonder what can be done in the
area of concurrency (in some form), a new language under the hood (Guile?),
etc.

Emacs is my favorite application, by far, and the one I spend the most time
in, both professionally and personally. It's my programming environment,
E-mail reader, IRC client, task manager, note taker, and occasional shell. I'm
hoping it will still be the best choice for these things after twenty _more_
years of use, and perhaps as head maintainer I could help keep things moving
in that direction.

John

Re: New maintainer

[Andreas Röhler]

Am 29.09.2015 um 23:46 schrieb John Wiegley:
>>>>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> So, now that I stepped down, we need to find a new maintainer (or a new
>> maintainer-team).
> I'd like to self-nominate for that role, Stefan. I've been contributing to
> Emacs since 1994, and have loved it all the while. Emacs Lisp remains a very
> enjoyable language to write certain types of code in.
>
> Some things I'd like to see happen to Emacs are more efficiency, closing bugs,
> and wider adoption of some of our newest features, like lexical scoping. That
> said, I'm also excited by new prospects, and wonder what can be done in the
> area of concurrency (in some form), a new language under the hood (Guile?),
> etc.
>
> Emacs is my favorite application, by far, and the one I spend the most time
> in, both professionally and personally. It's my programming environment,
> E-mail reader, IRC client, task manager, note taker, and occasional shell. I'm
> hoping it will still be the best choice for these things after twenty _more_
> years of use, and perhaps as head maintainer I could help keep things moving
> in that direction.
>
> John
>
>

Hi John,

knowing you as author of some really awesome libraries,

not just http://www.ledger-cli.org

would be interesting to see you heading the beast.

BTW your github account is hard to find by your name --sorry being 
stupid--, may you provide it?

Thanks Stefan for all the work done,

Andreas

Re: New maintainer

[Tassilo Horn]

Andreas Röhler <andreas.roehler@online.de> writes:

> BTW your github account is hard to find by your name --sorry being
> stupid--, may you provide it?

http://lmgtfy.com/?q=John+Wiegley+github&l=1

;-)

Bye,
Tassilo

Re: New maintainer

[Xue Fuqiao]

On Thu, Oct 1, 2015 at 2:12 PM, Andreas Röhler
<andreas.roehler@online.de> wrote:
> knowing you as author of some really awesome libraries,

I agree.  John is a very smart Emacs hacker.  IIRC he is the author of
(at least) align.el, cal-bahai.el, eudcb-mab.el, isearchb.el,
pcmpl-cvs.el, pcomplete.el, remember.el, timeclock.el, Eshell, and the
`use-package' macro.  He has also contributed to Org and some other
Emacs packages.  I think most Emacs users have used his code.  Besides
Emacs Lisp, he's also quite familiar with many other languages, such as
Common Lisp, C++, Java, and Haskell.

> BTW your github account is hard to find by your name --sorry being stupid--,
> may you provide it?

It's here: https://github.com/jwiegley

Re: New maintainer

[Mathieu Lirzin]

Xue Fuqiao <xfq.free@gmail.com> writes:

> On Thu, Oct 1, 2015 at 2:12 PM, Andreas Röhler
> <andreas.roehler@online.de> wrote:
>> knowing you as author of some really awesome libraries,
>
> I agree.  John is a very smart Emacs hacker.  IIRC he is the author of
> (at least) align.el, cal-bahai.el, eudcb-mab.el, isearchb.el,
> pcmpl-cvs.el, pcomplete.el, remember.el, timeclock.el, Eshell, and the
> `use-package' macro.  He has also contributed to Org and some other
> Emacs packages.  I think most Emacs users have used his code.  Besides
> Emacs Lisp, he's also quite familiar with many other languages, such as
> Common Lisp, C++, Java, and Haskell.

What about Ethical skills?  I would argue that technical skills are not
sufficient especially for maintaining a major GNU package like Emacs.
Using MacOSX & iOS as main operating systems and Hangout/Skype for
communications, seems incompatible with the role to me.

--
Mathieu Lirzin

Re: New maintainer

[John Wiegley]

>>>>> Mathieu Lirzin <mthl@openmailbox.org> writes:

> What about Ethical skills? I would argue that technical skills are not
> sufficient especially for maintaining a major GNU package like Emacs. Using
> MacOSX & iOS as main operating systems and Hangout/Skype for communications,
> seems incompatible with the role to me.

I also disagree with the spirit of the GPL, vocally in fact. If the requisite
for maintaining Emacs is that one use (GNU/)Linux and espouse the philosophies
of RMS, that is not me.

However: are you looking for someone to act as an arm of the FSF, or do you
want the best possible Emacs?

John

Re: New maintainer

[Yoni Rabkin]

> However: are you looking for someone to act as an arm of the FSF, or
> do you want the best possible Emacs?

You've manufactured that distinction artificially in order to make
people think that the two are mutually exclusive. Please don't do
that. How can it be the best possible GNU/Emacs if it doesn't respect my
freedom?

-- 
   "Cut your own wood and it will warm you twice"

Re: New maintainer

[John Wiegley]

>>>>> Yoni Rabkin <yoni@rabkins.net> writes:

> You've manufactured that distinction artificially in order to make people
> think that the two are mutually exclusive. Please don't do that. How can it
> be the best possible GNU/Emacs if it doesn't respect my freedom?

I have contrasted attending to the politics of the FSF with the technical
needs of Emacs, and asked which one was primary in the search for a
maintainer. That is all.

>>>>> David Kastrup <dak@gnu.org> writes:

> I wouldn't go as far as calling this "ethical skills" but yes, it seems like
> a cultural mismatch that would appear likely to cause considerable friction
> in choosing consistent priorities for ongoing development.

It's possible this is true. I don't seek to change anything about Emacs from a
legal standpoint, but I would be more vocal in wanting better support for non-
GNU platforms, such as OS X.

If this makes me an undesirable candidate, that's quite understandable. But
know that first and foremost I care about *Emacs*, and not the politics of the
FSF. If that's more important than technical considerations, let the
maintainer be chosen accordingly.

John

Re: New maintainer

[Dmitry Gutov]

On 10/02/2015 03:38 AM, John Wiegley wrote:

> It's possible this is true. I don't seek to change anything about Emacs from a
> legal standpoint, but I would be more vocal in wanting better support for non-
> GNU platforms, such as OS X.

Better than GNU platforms? The only relevant "political" hurdle there 
AFAIK is that we don't add features that work on proprietary platforms, 
but don't work (or work considerably worse) on GNU platforms.

Re: New maintainer

[John Wiegley]

>>>>> Dmitry Gutov <dgutov@yandex.ru> writes:

> Better than GNU platforms? The only relevant "political" hurdle there AFAIK
> is that we don't add features that work on proprietary platforms, but don't
> work (or work considerably worse) on GNU platforms.

No, not better than GNU. Just not red-headed step-child worse. :)

I would not want to invest time in features that only a subset of the
community would care to maintain. But those features that should available
everywhere, should function equivalently well on all supported platforms.

John

Re: New maintainer

[Dmitry Gutov]

On 10/02/2015 03:49 AM, John Wiegley wrote:

> I would not want to invest time in features that only a subset of the
> community would care to maintain. But those features that should available
> everywhere, should function equivalently well on all supported platforms.

That shouldn't be a problem. But there's no need to be "more vocal", 
then - just roll up the sleeves and go at it. :)

Re: New maintainer

[David Kastrup]

"John Wiegley" <johnw@newartisans.com> writes:

>>>>>> Yoni Rabkin <yoni@rabkins.net> writes:
>
>> You've manufactured that distinction artificially in order to make people
>> think that the two are mutually exclusive. Please don't do that. How can it
>> be the best possible GNU/Emacs if it doesn't respect my freedom?
>
> I have contrasted attending to the politics of the FSF with the technical
> needs of Emacs, and asked which one was primary in the search for a
> maintainer. That is all.
>
>>>>>> David Kastrup <dak@gnu.org> writes:
>
>> I wouldn't go as far as calling this "ethical skills" but yes, it
>> seems like a cultural mismatch that would appear likely to cause
>> considerable friction in choosing consistent priorities for ongoing
>> development.
>
> It's possible this is true. I don't seek to change anything about
> Emacs from a legal standpoint, but I would be more vocal in wanting
> better support for non- GNU platforms, such as OS X.

You could start by telling Apple to make its terms and conditions for
XCode compatible with creating and distributing software without
requiring a native OSX installation (which is not feasible when
targetting multiple platforms with crosscompilation).

Because that's kind of a bummer.  Where is the point in promoting a
portable compiler chain ike Clang/LLVM if you are precluded from using
it for, well, porting stuff to OSX?

The necessity for maintaining a _natively_ compiled port of OSX is a
really big setback for supporting a diverse set of platforms and leads
to a fragmentation of efforts.

Getting ideological about this saves oneself from sinking an arbitrary
amount of effort in endeavors that are constantly under threats outside
of the developers' control and can be killed at the whim of parties not
interested in free software.

I don't want an Emacs maintainer ultimately banking on the goodwill of
Apple regarding the invested efforts.  That's not an inspiring work
environment.

-- 
David Kastrup

Re: New maintainer

[John Wiegley]

>>>>> David Kastrup <dak@gnu.org> writes:

> Getting ideological about this saves oneself from sinking an arbitrary
> amount of effort in endeavors that are constantly under threats outside of
> the developers' control and can be killed at the whim of parties not
> interested in free software.
>
> I don't want an Emacs maintainer ultimately banking on the goodwill of Apple
> regarding the invested efforts. That's not an inspiring work environment.

I'm bitten by this _regularly_ in the Nix world, so I'm not seeking to tether
anyone to the developer churn happening over at Apple. Just this week I had to
downgrade to XCode 6.4, because 7.0 broke my entire world.

My OS X story for Emacs is mostly this: Give Mitsuharu Yamamoto whatever help
he needs. His "Mac port" variant of Emacs is all I could ask for in terms of
OS X support right now. I'd like to see it modernized under Cocoa, if at all
possible, or promoted to a build flavor in the master branch.

I'm not talking about upheaval here, just equal footing, and paying attention
to OS X (and other platform) gripes as they arise -- like the slow sub-process
bug in Cocoa Emacs that has been a show-stopper for some of us for several
years now.

You'll find I'm upfront with my opinions, but it's not my desire to alienate
*anyone* from participating, joyfully, in making Emacs a great community and
development experience.

John

Re: New maintainer

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > My OS X story for Emacs is mostly this: Give Mitsuharu Yamamoto
  > whatever help he needs. His "Mac port" variant of Emacs is all I
  > could ask for in terms of OS X support right now. I'd like to see
  > it modernized under Cocoa, if at all possible, or promoted to a
  > build flavor in the master branch.

That would go against the goals of the GNU Project, both practically
and in principle.  It would be a very strong commitment to a system
that exemplifies the injustice we aim to get rid of.  It would be
utterly backwards.

  > I'm not talking about upheaval here, just equal footing,

It would be wrong and harmful to give MacOS an "equal footing".
Our goal is to replace nonfree systems (and nonfree software in
general), not to enhance them.

We measure improvement of GNU Emacs in terms of what it can do as part
of the GNU system.  What happens on MacOS or Windows does not count.

See the section "Platforms to Support", in Information for Maintainers
of GNU Software.

We do include support for MacOS and Windows, to the extent people
develop such support and it isn't a problem to include; but we reject
any obligation to support them.  Making that an obligation would
legitimize those systems -- and go against our goal, which is to beat
them -- and divert effort to something that doesn't count.

If the Emacs maintainers rejected features that work only on GNU-like
systems, saying "You must add support for Windows and MacOS before we
can install this," that would pressure our contributors to use
proprietary systems (it is unethical even to suggest people use
them!).  That requirement would hold back contribution from developers
that don't use them.  It would thus impede the improvement of GNU
Emacs (which means, making it function better in GNU).

Thus, it is unacceptable to require Windows or MacOS support before
installing contributions.  A contribution only HAS to work on GNU (but
it should be conditionalized so it does not break Emacs on the other
platforms it doesn't support), but we should try to keep it working on
*BSD since that is usually easy.  As for Windows and MacOS support, we
can integrate that if and when someone provides it.

There is nothing wrong with an Emacs maintainer's writing code to
support for Windows or MacOS.  However, if the maintainers have
limited time for Emacs, spending much time supporting secondary
platforms could leave the Emacs maintainers' main job starved for
time.  That would be a practical problem, if it happens.  Perhaps
it won't happen.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: New maintainer

[Andreas Röhler]

Am 03.10.2015 um 03:37 schrieb Richard Stallman:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>    > My OS X story for Emacs is mostly this: Give Mitsuharu Yamamoto
>    > whatever help he needs. His "Mac port" variant of Emacs is all I
>    > could ask for in terms of OS X support right now. I'd like to see
>    > it modernized under Cocoa, if at all possible, or promoted to a
>    > build flavor in the master branch.
>
> That would go against the goals of the GNU Project, both practically
> and in principle.  It would be a very strong commitment to a system
> that exemplifies the injustice we aim to get rid of.  It would be
> utterly backwards.
>
>    > I'm not talking about upheaval here, just equal footing,
>
> It would be wrong and harmful to give MacOS an "equal footing".
> Our goal is to replace nonfree systems (and nonfree software in
> general), not to enhance them.
>
> We measure improvement of GNU Emacs in terms of what it can do as part
> of the GNU system.  What happens on MacOS or Windows does not count.
>
> See the section "Platforms to Support", in Information for Maintainers
> of GNU Software.
>
> We do include support for MacOS and Windows, to the extent people
> develop such support and it isn't a problem to include; but we reject
> any obligation to support them.  Making that an obligation would
> legitimize those systems -- and go against our goal, which is to beat
> them -- and divert effort to something that doesn't count.
>
> If the Emacs maintainers rejected features that work only on GNU-like
> systems, saying "You must add support for Windows and MacOS before we
> can install this," that would pressure our contributors to use
> proprietary systems (it is unethical even to suggest people use
> them!).  That requirement would hold back contribution from developers
> that don't use them.  It would thus impede the improvement of GNU
> Emacs (which means, making it function better in GNU).
>
> Thus, it is unacceptable to require Windows or MacOS support before
> installing contributions.  A contribution only HAS to work on GNU (but
> it should be conditionalized so it does not break Emacs on the other
> platforms it doesn't support), but we should try to keep it working on
> *BSD since that is usually easy.  As for Windows and MacOS support, we
> can integrate that if and when someone provides it.
>
> There is nothing wrong with an Emacs maintainer's writing code to
> support for Windows or MacOS.  However, if the maintainers have
> limited time for Emacs, spending much time supporting secondary
> platforms could leave the Emacs maintainers' main job starved for
> time.  That would be a practical problem, if it happens.  Perhaps
> it won't happen.
>

Hi Richard,

+1

Thanks for clarification.

Any response from Eli WRT acting as co-maintainer?

Would be great to see both in office ASAP.

Cheers,

Andreas

Re: New maintainer

[John Wiegley]

>>>>> Richard Stallman <rms@gnu.org> writes:

> We measure improvement of GNU Emacs in terms of what it can do as part of
> the GNU system. What happens on MacOS or Windows does not count.

I can see how this provides clear focus for the FSF in supporting Emacs, no
argument here.

> We do include support for MacOS and Windows, to the extent people develop
> such support and it isn't a problem to include; but we reject any obligation
> to support them. Making that an obligation would legitimize those systems --
> and go against our goal, which is to beat them -- and divert effort to
> something that doesn't count.

OK, as long as the FSF isn't actively getting in the way of such support, to
intentionally cripple those systems to make GNU seem better. GNU should *be*
better if it is to succeed, not position itself as the best of the worst.

> If the Emacs maintainers rejected features that work only on GNU-like
> systems, saying "You must add support for Windows and MacOS before we can
> install this," that would pressure our contributors to use proprietary
> systems (it is unethical even to suggest people use them!). That requirement
> would hold back contribution from developers that don't use them. It would
> thus impede the improvement of GNU Emacs (which means, making it function
> better in GNU).

I don't recognize your authority to tell me what is and is not ethical,
Richard, and think you should stop using words like "injustice" and
"inethical" in your presentations. Not everyone agrees with you, so calling
them wrong to paint yourself as right does little service to your cause.

If you present the benefits and virtue of GNU-like systems, it gives weight to
your message. But standing out by demonizing opponents is a horse that
politicians have beat to death, and has never, ever led to lasting success.

> Thus, it is unacceptable to require Windows or MacOS support before
> installing contributions. A contribution only HAS to work on GNU (but it
> should be conditionalized so it does not break Emacs on the other platforms
> it doesn't support), but we should try to keep it working on *BSD since that
> is usually easy. As for Windows and MacOS support, we can integrate that if
> and when someone provides it.
>
> There is nothing wrong with an Emacs maintainer's writing code to support
> for Windows or MacOS. However, if the maintainers have limited time for
> Emacs, spending much time supporting secondary platforms could leave the
> Emacs maintainers' main job starved for time. That would be a practical
> problem, if it happens. Perhaps it won't happen.

Again, I can't argue with this as FSF policy. Only that, since I use OS X
daily, this is the Emacs I experience, and it colors my perception of how well
Emacs is doing. If the experience is great on GNU systems, but awful on OS X,
I'll see this as meaning that changes needing to be made. Conversely, I won't
notice degradation on GNU systems owing to cross-platform changes, and would
require those using such systems to inform me.

So there are probably much better candidates than I for achieving the best
"GNU Emacs", instead of the broader definition of "Emacs for all supported
platforms" that I have in mind. Note too that the latter is very likely what
most Emacs users in the world think of when they think of a "better Emacs"; I
imagine only a subset of those using Emacs do so to promote GNU more than to
edit files.

Eli Zaretskii wrote:

> So, given this seemingly unsolvable contradiction, what do you, the crowd,
> expect of the new maintainer? What "job description", in addition to what
> Richard wrote, would you propose if you were tasked with the job of finding
> the candidates? E.g., how many hours a week should that person be available
> for working on Emacs? Which talents and personal traits should he or she
> possess? Etc. etc.

I think this is a great next step. We need a proper "job description",
including objectives, responsibilities, expectations, and what should define a
successful tenure.

John

Re: New maintainer

[David Kastrup]

"John Wiegley" <johnw@newartisans.com> writes:

> I don't recognize your authority to tell me what is and is not
> ethical, Richard, and think you should stop using words like
> "injustice" and "inethical" in your presentations. Not everyone agrees
> with you, so calling them wrong to paint yourself as right does little
> service to your cause.
>
> If you present the benefits and virtue of GNU-like systems, it gives
> weight to your message. But standing out by demonizing opponents is a
> horse that politicians have beat to death, and has never, ever led to
> lasting success.

Uh, it's the fundamental tenet of the GNU project.  Free Software's
value does not rest on relative benefits and virtues but on the
fundamental software freedoms.  The stance of the FSF fundamentally
differs from that of the "Open Source" software camp which tries to
paint Free Software as a superior development model, consequently giving
a nod to proprietary software as long as it is successful.

With that stance, Free Software would never have gotten off the ground
since it by necessity started inferior to existing proprietary
solutions.

The whole point of GNU is the non-acceptance of software denying the
users the fundamental software freedoms.  This constitutes a moral
judgment and as such is indistinguishable from "demonizing opponents" or
at the very least damning their actions.

So it would be pointless to ask for change on that front.  It's what
makes this show ultimately tick.

-- 
David Kastrup

Re: New maintainer

[John Wiegley]

>>>>> David Kastrup <dak@gnu.org> writes:

> Uh, it's the fundamental tenet of the GNU project. Free Software's value
> does not rest on relative benefits and virtues but on the fundamental
> software freedoms. The stance of the FSF fundamentally differs from that of
> the "Open Source" software camp which tries to paint Free Software as a
> superior development model, consequently giving a nod to proprietary
> software as long as it is successful.

Thanks for clarifying that, David, I very much appreciate your tone of
presentation.

> The whole point of GNU is the non-acceptance of software denying the users
> the fundamental software freedoms. This constitutes a moral judgment and as
> such is indistinguishable from "demonizing opponents" or at the very least
> damning their actions.

Then I respectfully withdraw myself as a candidate for maintainer. Damning by
implication is one thing; setting out to defame other organizations in order
to make one's own appear the standard of virtue is something else entirely,
and I do not wish to be associated with such methods.

Thanks to all for their supporting words and encouragement, and to the FSF for
having this frank and open discussion with me on the issues that matter.

John

Re: New maintainer

[David Kastrup]

"John Wiegley" <johnw@newartisans.com> writes:

>>>>>> David Kastrup <dak@gnu.org> writes:
>
>> Uh, it's the fundamental tenet of the GNU project. Free Software's value
>> does not rest on relative benefits and virtues but on the fundamental
>> software freedoms. The stance of the FSF fundamentally differs from that of
>> the "Open Source" software camp which tries to paint Free Software as a
>> superior development model, consequently giving a nod to proprietary
>> software as long as it is successful.
>
> Thanks for clarifying that, David, I very much appreciate your tone of
> presentation.
>
>> The whole point of GNU is the non-acceptance of software denying the users
>> the fundamental software freedoms. This constitutes a moral judgment and as
>> such is indistinguishable from "demonizing opponents" or at the very least
>> damning their actions.
>
> Then I respectfully withdraw myself as a candidate for
> maintainer. Damning by implication is one thing; setting out to defame
> other organizations in order to make one's own appear the standard of
> virtue is something else entirely, and I do not wish to be associated
> with such methods.
>
> Thanks to all for their supporting words and encouragement, and to the
> FSF for having this frank and open discussion with me on the issues
> that matter.

Let me make clear here that I do not speak for the FSF and am neither a
member nor a representative of it.  So nothing I say constitutes any
official statement by the FSF.  I merely spent enough time discussing
such matters that I believe myself to rarely end up far off the mark.

-- 
David Kastrup

Re: New maintainer

[Andreas Röhler]

Am 03.10.2015 um 21:26 schrieb John Wiegley:
>>>>>> David Kastrup <dak@gnu.org> writes:
>> Uh, it's the fundamental tenet of the GNU project. Free Software's value
>> does not rest on relative benefits and virtues but on the fundamental
>> software freedoms. The stance of the FSF fundamentally differs from that of
>> the "Open Source" software camp which tries to paint Free Software as a
>> superior development model, consequently giving a nod to proprietary
>> software as long as it is successful.
> Thanks for clarifying that, David, I very much appreciate your tone of
> presentation.
>
>> The whole point of GNU is the non-acceptance of software denying the users
>> the fundamental software freedoms. This constitutes a moral judgment and as
>> such is indistinguishable from "demonizing opponents" or at the very least
>> damning their actions.
> Then I respectfully withdraw myself as a candidate for maintainer. Damning by
> implication is one thing; setting out to defame other organizations in order
> to make one's own appear the standard of virtue is something else entirely,
> and I do not wish to be associated with such methods.
>
> Thanks to all for their supporting words and encouragement, and to the FSF for
> having this frank and open discussion with me on the issues that matter.
>
> John
>
>


Don't think a moral is 'indistinguishable from demonizing opponents", as 
David writes. That's a misguided pseudo-religous approach. Also AFAIK 
it's not the declared FSF policy.

Cheers,

Andreas

Re: New maintainer

[David Kastrup]

Andreas Röhler <andreas.roehler@online.de> writes:

> Am 03.10.2015 um 21:26 schrieb John Wiegley:
>>>>>>> David Kastrup <dak@gnu.org> writes:
>>
>>> The whole point of GNU is the non-acceptance of software denying the
>>> users the fundamental software freedoms. This constitutes a moral
>>> judgment and as such is indistinguishable from "demonizing
>>> opponents" or at the very least damning their actions.

>> Then I respectfully withdraw myself as a candidate for
>> maintainer. Damning by implication is one thing; setting out to
>> defame other organizations in order to make one's own appear the
>> standard of virtue is something else entirely,

And not at all what I have been saying.

>> and I do not wish to be associated with such methods.
>>
>> Thanks to all for their supporting words and encouragement, and to
>> the FSF for having this frank and open discussion with me on the
>> issues that matter.
>
> Don't think a moral is 'indistinguishable from demonizing opponents",
> as David writes. That's a misguided pseudo-religous approach. Also
> AFAIK it's not the declared FSF policy.

<URL:https://www.gnu.org/philosophy/free-software-even-more-important.html>

    Since 1983, the Free Software Movement has campaigned for computer
    users' freedom—for users to control the software they use, rather
    than vice versa. When a program respects users' freedom and
    community, we call it “free software.”

    We also sometimes call it “libre software” to emphasize that we're
    talking about liberty, not price. Some proprietary (nonfree)
    programs, such as Photoshop, are very expensive; others, such as
    Flash Player, are available gratis—but that's a minor detail. Either
    way, they give the program's developer power over the users, power
    that no one should have.

    Those two nonfree programs have something else in common: they are
    both malware. That is, both have functionalities designed to
    mistreat the user. Proprietary software nowadays is often malware
    because the developers' power corrupts them.

    With free software, the users control the program, both individually
    and collectively. So they control what their computers do (assuming
    those computers are loyal and do what the users' programs tell them
    to do).

    With proprietary software, the program controls the users, and some
    other entity (the developer or “owner”) controls the program. So the
    proprietary program gives its developer power over its users. That
    is unjust in itself, and tempts the developer to mistreat the users
    in other ways.

I don't think that I am wide off the mark with regard to the statement
I actually made rather than John's interpretation of it.

-- 
David Kastrup

Re: New maintainer

[John Wiegley]

>>>>> David Kastrup <dak@gnu.org> writes:

>>> Damning by implication is one thing; setting out to defame other
>>> organizations in order to make one's own appear the standard of virtue is
>>> something else entirely,

> And not at all what I have been saying.

Maybe not what you've been saying here, but what the FSF has been doing. The
way RMS talks about Apple and other companies, using words like unethical,
corrupted, evil; I can't get behind that sort of rhetoric.

But I knew I had differences with RMS before this, so that's not changed. I
also know that I love Emacs and want to help it remain my editor of choice for
a long time to come. If I can serve Emacs independently, from RMS and his
agenda, I'm happy to do so, whether it benefits the FSF's cause or not.

What RMS may not know is that I respect his spirit, the intentions behind his
actions, and the effect he has had on our world as a whole. Free software in
general (if not "libre" software) is without a doubt more real today because
of him, and I've directly benefited from those efforts, both personally and
professionally. So the FSF always has some credit in my bank, so to speak. If
GNU/Linux could be an awesome OS with awesome applications, I wouldn't use my
OS X machine anymore.

What bothers me are the socialistic aspects involved, the _way_ RMS demonizes
other approaches to licensing (eerily similar to how socialism demonizes other
political philosophies), and the way he talks about "freedom" -- while what is
meant is specifically the freedom of the user/consumer, and not the freedom of
the developer/producer. These are reasons I do not support his path as leading
toward true liberty. I _do_ want to true liberty, and for all software to be
as free as RMS could ever want to to be; I just don't believe in getting there
this way.

John

Re: New maintainer

[Juanma Barranquero]

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

On Sat, Oct 3, 2015 at 10:44 PM, John Wiegley <johnw@newartisans.com> wrote:

> What bothers me are the socialistic aspects involved, the _way_ RMS
demonizes
> other approaches to licensing (eerily similar to how socialism demonizes
other
> political philosophies),

Perhaps we should leave non-software-related politics out of this
discussion. Reading "socialistic" as a pejorative could be a bit jarring
for some of us.

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

Re: New maintainer

[John Wiegley]

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

> Perhaps we should leave non-software-related politics out of this
> discussion. Reading "socialistic" as a pejorative could be a bit jarring for
> some of us.

Agreed, Juanma, with my apologies. I had meant to imply certain historical
experiments with negative outcomes, but not to erase the positive aspects of
socialism altogether. I'll refrain from such examples in the future.

John

Re: New maintainer

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sat, 3 Oct 2015 23:49:16 +0200
> 
> On Sat, Oct 3, 2015 at 10:44 PM, John Wiegley <johnw@newartisans.com> wrote:
> 
> > What bothers me are the socialistic aspects involved, the _way_ RMS demonizes
> > other approaches to licensing (eerily similar to how socialism demonizes
> other
> > political philosophies),
> 
> Perhaps we should leave non-software-related politics out of this discussion.

I agree.

Please also keep in mind that AFAIK a possibility exists to more or
less split these two parts, by nominating a "steering committee" for
the project, which will act as the FSF representative and deal with
most of these issues.  Several projects (GCC and GDB, to give just 2
examples) already have that, although the split is not very strong
there (because there's no need, IIUC).

Richard, please correct me if I'm wrong in my understanding.

Re: New maintainer

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I say that nonfree software licenses are an injustice, but that is not
"demonizing".  I focus criticism mainly on the programs rather than
the people that develop them.

As regards non-copyleft free licenses, I say they are ethically
acceptible but weak.  A free program under a pushover license is
better than no free program at all.  This is not demonization; it is
praise with caveat.  It is not glowing praise, but nonetheless praise.
See http://gnu.org/licenses/license-list.html.

See http://gnu.org/copyleft/ for more explanation of this issue.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: New maintainer

[Jean-Christophe Helary]

> On Oct 4, 2015, at 05:44, John Wiegley <johnw@newartisans.com> wrote:

> What bothers me are the socialistic aspects involved, the _way_ RMS demonizes
> other approaches to licensing (eerily similar to how socialism demonizes other
> political philosophies),

You've not been watching the news in the past 100 years. Socialism is the philosophy that has been the most demonised. Your comment only shows a gross misunderstanding of political history and of the aspirations of the people who gave their lives so that more people could achieve freedom from economic serfdom regardless of what self-proclaimed tyrants did or said. We're not on Fox News here are we?

Jean-Christophe Helary

Re: New maintainer

[John Wiegley]

>>>>> Jean-Christophe Helary <jean.christophe.helary@gmail.com> writes:

> You've not been watching the news in the past 100 years. Socialism is the
> philosophy that has been the most demonised. Your comment only shows a gross
> misunderstanding of political history and of the aspirations of the people
> who gave their lives so that more people could achieve freedom from economic
> serfdom regardless of what self-proclaimed tyrants did or said. We're not on
> Fox News here are we?

Not even sure what to say to that Jean-Christophe, except that here is not the
place. I fully retract my own demonization of socialism per se, so let's back
away from this particular cliff...

John

Re: New maintainer

[Lennart Borgman]

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

On Sun, Oct 4, 2015 at 12:53 AM, John Wiegley <johnw@newartisans.com> wrote:

> >>>>> Jean-Christophe Helary <jean.christophe.helary@gmail.com> writes:
>
> > You've not been watching the news in the past 100 years. Socialism is the
> > philosophy that has been the most demonised. Your comment only shows a
> gross
> > misunderstanding of political history and of the aspirations of the
> people
> > who gave their lives so that more people could achieve freedom from
> economic
> > serfdom regardless of what self-proclaimed tyrants did or said. We're
> not on
> > Fox News here are we?
>
> Not even sure what to say to that Jean-Christophe, except that here is not
> the
> place. I fully retract my own demonization of socialism per se, so let's
> back
> away from this particular cliff...
>
> John
>
>
When developing software together with other people I have always found it
saves a lot of time to focus on the intention with the code, what it is
supposed to do. I usually only look at the details if I have too. ;-)

Maybe discussions could learn a bit from this? (Even if they are very
different. We can't run tests for example. But we can take the discussions
further by trying to find the positive aspects of other peoples view.)

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

Re: New maintainer

[Andreas Röhler]

Am 03.10.2015 um 22:10 schrieb David Kastrup:
> Andreas Röhler <andreas.roehler@online.de> writes:
>
>> Am 03.10.2015 um 21:26 schrieb John Wiegley:
>>>>>>>> David Kastrup <dak@gnu.org> writes:
>>>> The whole point of GNU is the non-acceptance of software denying the
>>>> users the fundamental software freedoms. This constitutes a moral
>>>> judgment and as such is indistinguishable from "demonizing
>>>> opponents" or at the very least damning their actions.
>>> Then I respectfully withdraw myself as a candidate for
>>> maintainer. Damning by implication is one thing; setting out to
>>> defame other organizations in order to make one's own appear the
>>> standard of virtue is something else entirely,
> And not at all what I have been saying.
>
>>> and I do not wish to be associated with such methods.
>>>
>>> Thanks to all for their supporting words and encouragement, and to
>>> the FSF for having this frank and open discussion with me on the
>>> issues that matter.
>> Don't think a moral is 'indistinguishable from demonizing opponents",
>> as David writes. That's a misguided pseudo-religous approach. Also
>> AFAIK it's not the declared FSF policy.
> <URL:https://www.gnu.org/philosophy/free-software-even-more-important.html>
>
>      Since 1983, the Free Software Movement has campaigned for computer
>      users' freedom—for users to control the software they use, rather
>      than vice versa. When a program respects users' freedom and
>      community, we call it “free software.”
>
>      We also sometimes call it “libre software” to emphasize that we're
>      talking about liberty, not price. Some proprietary (nonfree)
>      programs, such as Photoshop, are very expensive; others, such as
>      Flash Player, are available gratis—but that's a minor detail. Either
>      way, they give the program's developer power over the users, power
>      that no one should have.
>
>      Those two nonfree programs have something else in common: they are
>      both malware. That is, both have functionalities designed to
>      mistreat the user. Proprietary software nowadays is often malware
>      because the developers' power corrupts them.
>
>      With free software, the users control the program, both individually
>      and collectively. So they control what their computers do (assuming
>      those computers are loyal and do what the users' programs tell them
>      to do).
>
>      With proprietary software, the program controls the users, and some
>      other entity (the developer or “owner”) controls the program. So the
>      proprietary program gives its developer power over its users. That
>      is unjust in itself, and tempts the developer to mistreat the users
>      in other ways.
>
> I don't think that I am wide off the mark with regard to the statement
> I actually made rather than John's interpretation of it.
>

Sorry, can't read anything which justifies or encourages "demonizing 
opponents" or "at the very least damning their actions." Consider your 
conclusion not just wrong but contra-productive. The liberation effort 
of the soviets died from these kind of treatment.

Re: New maintainer

[David Kastrup]

Andreas Röhler <andreas.roehler@online.de> writes:

> Am 03.10.2015 um 22:10 schrieb David Kastrup:
>> Andreas Röhler <andreas.roehler@online.de> writes:
>>
>>> Am 03.10.2015 um 21:26 schrieb John Wiegley:
>>>>>>>>> David Kastrup <dak@gnu.org> writes:
>>>>> The whole point of GNU is the non-acceptance of software denying the
>>>>> users the fundamental software freedoms. This constitutes a moral
>>>>> judgment and as such is indistinguishable from "demonizing
>>>>> opponents" or at the very least damning their actions.
>>>> Then I respectfully withdraw myself as a candidate for
>>>> maintainer. Damning by implication is one thing; setting out to
>>>> defame other organizations in order to make one's own appear the
>>>> standard of virtue is something else entirely,
>> And not at all what I have been saying.
>>
>>>> and I do not wish to be associated with such methods.
>>>>
>>>> Thanks to all for their supporting words and encouragement, and to
>>>> the FSF for having this frank and open discussion with me on the
>>>> issues that matter.
>>> Don't think a moral is 'indistinguishable from demonizing opponents",
>>> as David writes. That's a misguided pseudo-religous approach. Also
>>> AFAIK it's not the declared FSF policy.
>> <URL:https://www.gnu.org/philosophy/free-software-even-more-important.html>
>>
>>      Since 1983, the Free Software Movement has campaigned for computer
>>      users' freedom—for users to control the software they use, rather
>>      than vice versa. When a program respects users' freedom and
>>      community, we call it “free software.”
>>
>>      We also sometimes call it “libre software” to emphasize that we're
>>      talking about liberty, not price. Some proprietary (nonfree)
>>      programs, such as Photoshop, are very expensive; others, such as
>>      Flash Player, are available gratis—but that's a minor detail. Either
>>      way, they give the program's developer power over the users, power
>>      that no one should have.
>>
>>      Those two nonfree programs have something else in common: they are
>>      both malware. That is, both have functionalities designed to
>>      mistreat the user. Proprietary software nowadays is often malware
>>      because the developers' power corrupts them.
>>
>>      With free software, the users control the program, both individually
>>      and collectively. So they control what their computers do (assuming
>>      those computers are loyal and do what the users' programs tell them
>>      to do).
>>
>>      With proprietary software, the program controls the users, and some
>>      other entity (the developer or “owner”) controls the program. So the
>>      proprietary program gives its developer power over its users. That
>>      is unjust in itself, and tempts the developer to mistreat the users
>>      in other ways.
>>
>> I don't think that I am wide off the mark with regard to the statement
>> I actually made rather than John's interpretation of it.
>>
>
> Sorry, can't read anything which justifies or encourages "demonizing
> opponents" or "at the very least damning their actions." Consider your
> conclusion not just wrong but contra-productive. The liberation effort
> of the soviets died from these kind of treatment.

Shrug.  I was quoting John's choice of words.  He stated:

    I don't recognize your authority to tell me what is and is not
    ethical, Richard, and think you should stop using words like
    "injustice" and "inethical" in your presentations. Not everyone
    agrees with you, so calling them wrong to paint yourself as right
    does little service to your cause.

    If you present the benefits and virtue of GNU-like systems, it gives
    weight to your message. But standing out by demonizing opponents is
    a horse that politicians have beat to death, and has never, ever led
    to lasting success.

In the end, it will be up to him to decide whether the paragraphs
I quoted are what he calls "demonizing opponents".  I considered it
likely that they were of the kind he was talking about and stated the
reasons for which I considered it unrealistic of John to expect any
change in that regard.

-- 
David Kastrup

Re: New maintainer

[John Wiegley]

>>>>> John Wiegley <johnw@newartisans.com> writes:

> Then I respectfully withdraw myself as a candidate for maintainer. Damning
> by implication is one thing; setting out to defame other organizations in
> order to make one's own appear the standard of virtue is something else
> entirely, and I do not wish to be associated with such methods.

It's been pointed out off-list that I was a bit too hasty in responding to
David's comments as if he represented the FSF in any way.

So I will withdraw my withdrawal, and say that if the opinions of the FSF, and
the maintenance of Emacs by someone like myself, can co-exist without
involving ethical compromise by either one of us, I'm happy for us to work
together.

The most important thing, even beyond the technical refinement of Emacs, is
the fostering of a supportive and active user community. Perhaps this means a
collaboritive maintainship, as suggested by Eli, though I'm still not sure
that is the wisest course of action. Happy to debate that in another thread,
though, if multiple maintainers should be chosen. If they are people I can
work with, then I'm certain a happy outcome can be found. If not, that alone
is proof we shouldn't be trying to lead together.

John

Re: New maintainer

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > So I will withdraw my withdrawal, and say that if the opinions of the FSF, and
  > the maintenance of Emacs by someone like myself, can co-exist without
  > involving ethical compromise by either one of us, I'm happy for us to work
  > together.

I hope that we can do do that, because you would bring great ability
to the job.

We have a deep disagreement, and neither of us is likely to change
position on the issue.  However, that disagreement does not
necessarily mean you can't be a maintainer, because all the GNU
Project really needs from a maintainer is to engage to carry out the
maintainer's responsibility.  So it is comes down to your decision
about that.

In practice, the parts of the responsibility that you'd need to
reconcile with your views are (1) accepting changes that work only on
GNU or GNU-like systems without reluctance, so as not to hold back the
advance of Emacs on those systems with contributions from people who
may not use or care about Windows or MacOS, and (2) and cooperating
with the things we do to present the GNU Project's positions in the
Emacs distribution itself (for instance, some material in etc and
doc).

I think it would be best to have two maintainers or three maintainers.
Stefan and Yidong worked well together as a team.  The fact that they
were two rather than three didn't hinder them from deciding.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: New maintainer

[John Wiegley]

>>>>> Richard Stallman <rms@gnu.org> writes:

> We have a deep disagreement, and neither of us is likely to change position
> on the issue. However, that disagreement does not necessarily mean you can't
> be a maintainer, because all the GNU Project really needs from a maintainer
> is to engage to carry out the maintainer's responsibility. So it is comes
> down to your decision about that.

> In practice, the parts of the responsibility that you'd need to reconcile
> with your views are (1) accepting changes that work only on GNU or GNU-like
> systems without reluctance, so as not to hold back the advance of Emacs on
> those systems with contributions from people who may not use or care about
> Windows or MacOS, and (2) and cooperating with the things we do to present
> the GNU Project's positions in the Emacs distribution itself (for instance,
> some material in etc and doc).

Thanks, Richard, that's really quite reasonable.

There is one technical matter that's been brought to my attention that I would
like to get your thoughts on:

In Emacs' future, I'd like to improve the way that external processes are used
to inform Emacs about the syntax and semantics of buffer contents. For
example, building completion lists, indexing code locations, looking up or
rendering documentation, etc.

I would like to achieve this in a general way, such that both GPL and non-GPL
software can be freely chosen by the Emacs user. For example, in C++ mode, one
could use either GCC or Clang (or both) to determine type information. It's
fine with me if only GCC support is actively endorsed, so long as the Clang
solution is equally feasible -- provided volunteers want to contribute to it,
and without detracting from the GCC support.

Some have told me off-list that you might be reluctant to allow even the
possibility of Clang being used in this scenario, since it might encourage use
of non-GNU software should its support prove superior. Since that doesn't seem
quite in keeping with the rational tone I read in your e-mail, I wanted to
check with you directly.

I can appreciate wanting Emacs to be a flagship GNU project, and to ensure
that GNU-favored technologies are not in any way damaged by supporting non-GNU
solutions. What I wonder is, if support for either option can be made purely a
matter of the user's choosing, without affecting Emacs' ability to make use of
GNU solutions, would this be opposed?

John

Re: New maintainer

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I would like to achieve this in a general way, such that both GPL and non-GPL
  > software can be freely chosen by the Emacs user. For example, in C++ mode, one
  > could use either GCC or Clang (or both) to determine type information. It's
  > fine with me if only GCC support is actively endorsed, so long as the Clang
  > solution is equally feasible -- provided volunteers want to contribute to it,
  > and without detracting from the GCC support.

If it really works usefully with GCC -- if that is not just a
theoretical idea -- then I won't object to its supporting other
compilers as well.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: New maintainer

[John Wiegley]

>>>>> Richard Stallman <rms@gnu.org> writes:

> If it really works usefully with GCC -- if that is not just a theoretical
> idea -- then I won't object to its supporting other compilers as well.

That's great to hear, Richard.

Any solution we choose should never preclude the opportunity for GCC to
outshine other choices. The main thing is that it is GCC's responsibility to
be better, and not Emacs' to prevent better options from being chosen, simply
to accommodate a lack of progress by GCC.

John

Re: New maintainer

[Dmitry Gutov]

On 10/05/2015 10:20 PM, John Wiegley wrote:

> Any solution we choose should never preclude the opportunity for GCC to
> outshine other choices. The main thing is that it is GCC's responsibility to
> be better, and not Emacs' to prevent better options from being chosen, simply
> to accommodate a lack of progress by GCC.

I'm assuming that's exactly what Richard meant by "theoretical idea". At 
least, it's how similar discussions went in the past.

Re: New maintainer

[Jay Belanger]

> If it really works usefully with GCC -- if that is not just a theoretical
> idea -- then I won't object to its supporting other compilers as well.

> On 10/05/2015 10:20 PM, John Wiegley wrote:

>> Any solution we choose should never preclude the opportunity for GCC to
>> outshine other choices. The main thing is that it is GCC's responsibility to
>> be better, and not Emacs' to prevent better options from being chosen, simply
>> to accommodate a lack of progress by GCC.

Dmitry Gutov <dgutov@yandex.ru> writes:

> I'm assuming that's exactly what Richard meant by "theoretical
> idea". At least, it's how similar discussions went in the past.

Maybe I'm misreading it, but it doesn't sound like what Richard meant at
all.  I read it as the features have to actually work with GCC ("not just a
theoretical idea") to be included.

Re: New maintainer

[Dmitry Gutov]

On 10/05/2015 10:31 PM, Jay Belanger wrote:

> Maybe I'm misreading it, but it doesn't sound like what Richard meant at
> all.  I read it as the features have to actually work with GCC ("not just a
> theoretical idea") to be included.

The issue is that GCC, in its current state, doesn't provide a certain 
set a features Emacs can take advantage of, that Clang does.

Re: New maintainer

[Jay Belanger]

>> Maybe I'm misreading it, but it doesn't sound like what Richard meant at
>> all.  I read it as the features have to actually work with GCC ("not just a
>> theoretical idea") to be included.
>
> The issue is that GCC, in its current state, doesn't provide a certain
> set a features Emacs can take advantage of, that Clang does.

That's the point.  It sounded like Richard was saying that in that case,
Emacs shouldn't take advantage of it.  How else could

> If it really works usefully with GCC -- if that is not just a theoretical
> idea -- then I won't object to its supporting other compilers as well.

be interpreted?

Re: New maintainer

[John Wiegley]

>>>>> Jay Belanger <jay.p.belanger@gmail.com> writes:

>>> Maybe I'm misreading it, but it doesn't sound like what Richard meant at
>>> all. I read it as the features have to actually work with GCC ("not just a
>>> theoretical idea") to be included.
>> 
>> The issue is that GCC, in its current state, doesn't provide a certain
>> set a features Emacs can take advantage of, that Clang does.

> That's the point. It sounded like Richard was saying that in that case,
> Emacs shouldn't take advantage of it. How else could

>> If it really works usefully with GCC -- if that is not just a theoretical
>> idea -- then I won't object to its supporting other compilers as well.

> be interpreted?

I interpret him as meaning that the support should not favor non-GCC compilers
in any way, not that GCC should determine the least upper bound on
functionality.

For example, an automobile can be driven by any able-bodied individual. It
does not favor one person over another, because it is adjustable. Both my wife
and I can drive the same cars, always.

A car does, however, favor ability. A better driver will drive any car better
than a worse driver. This does not preclude the worse driver from studying and
becoming better, however. It does not "build in" any advantage that makes one
driver better, no matter what the other driver does.

To me, Emacs is a vehicle for content, and external processes sometimes guide
or drive that content, such as GCC or Clang within a C++ buffer. Emacs should
be adjustable to allow either one to be used. Certainly one may provide better
functionality than the other, but Emacs itself should not favor one over the
other. If GCC ends up excelling Clang as a compiler, its Emacs support should
be capable of excelling Clang as well, without any change necessary from Emacs
to allow this.

If, on the other hand, Clang offered some clever API that was specific to
Clang, and we built support for that API directly into Emacs to allow a better
experience for Clang users, this is what Richard would not allow, according to
what I read.

John

Re: New maintainer

[David Engster]

John Wiegley writes:
> I interpret him as meaning that the support should not favor non-GCC compilers
> in any way, not that GCC should determine the least upper bound on
> functionality.

I'd suggest to read the past discussion on this to better understand
Richard's position. There's a good summary at LWN:

http://lwn.net/Articles/629259/

-David

Re: New maintainer

[John Wiegley]

>>>>> David Engster <deng@randomsample.de> writes:

> I'd suggest to read the past discussion on this to better understand
> Richard's position. There's a good summary at LWN:

> http://lwn.net/Articles/629259/

Stefan wrote:

> My understanding is that you're opposed to GCC providing this useful info
> because that info would need to be complete enough to be usable as input to
> a proprietary compiler backend.

Isn't crippling the output of GCC, to prevent use by proprietary vendors, a
direct example of limiting *our* freedom, as users who want access to that
information to improve our use of Emacs (or other tools)? Making such
information available does not make GCC or Emacs in any way more proprietary
or freedom-destroying. If anything, it is liberating the information known to
these applications, so that it can be more widely applied.

Richard, can you please clarify? I can appreciate not wanting to support,
favor, or even recommend, proprietary systems. But the discussion I'm reading
at that link feels different from this.

John

Re: New maintainer

[Jay Belanger]

"John Wiegley" <johnw@newartisans.com> writes:

> If, on the other hand, Clang offered some clever API that was specific
> to Clang, and we built support for that API directly into Emacs to
> allow a better experience for Clang users, this is what Richard would
> not allow, according to what I read.

Ah.  This sounds different than what you wrote before:

>> The main thing is that it is GCC's responsibility to be better, and
>> not Emacs' to prevent better options from being chosen, simply to
>> accommodate a lack of progress by GCC.

I took this to mean if Clang offered something that Emacs could support,
then it would be GCC's responsibility to add it.  But I'm probably
misunderstanding something.

Thanks for the answer.

Re: New maintainer

[David Kastrup]

Jay Belanger <jay.p.belanger@gmail.com> writes:

> "John Wiegley" <johnw@newartisans.com> writes:
>
>> If, on the other hand, Clang offered some clever API that was specific
>> to Clang, and we built support for that API directly into Emacs to
>> allow a better experience for Clang users, this is what Richard would
>> not allow, according to what I read.
>
> Ah.  This sounds different than what you wrote before:
>
>>> The main thing is that it is GCC's responsibility to be better, and
>>> not Emacs' to prevent better options from being chosen, simply to
>>> accommodate a lack of progress by GCC.
>
> I took this to mean if Clang offered something that Emacs could
> support, then it would be GCC's responsibility to add it.

If consistent with the technical possibilities and steering decisions.
Yes.

But it is Emacs' responsibility to wait until GCC does that before
supporting it on other platforms.

-- 
David Kastrup

Re: New maintainer

[David Kastrup]

"John Wiegley" <johnw@newartisans.com> writes:

>>>>>> Jay Belanger <jay.p.belanger@gmail.com> writes:
>
>>>> Maybe I'm misreading it, but it doesn't sound like what Richard meant at
>>>> all. I read it as the features have to actually work with GCC ("not just a
>>>> theoretical idea") to be included.
>>> 
>>> The issue is that GCC, in its current state, doesn't provide a certain
>>> set a features Emacs can take advantage of, that Clang does.
>
>> That's the point. It sounded like Richard was saying that in that case,
>> Emacs shouldn't take advantage of it. How else could
>
>>> If it really works usefully with GCC -- if that is not just a theoretical
>>> idea -- then I won't object to its supporting other compilers as well.
>
>> be interpreted?
>
> I interpret him as meaning that the support should not favor non-GCC
> compilers in any way, not that GCC should determine the least upper
> bound on functionality.

That interpretation is not supported by the mailing list history.  In
particular, there were (and still are) conscious restrictions to the
amount of information GCC may provide in a generic format and/or via a
generic plugin interface since such generic mechanisms define the
"application as a whole" border beyond which copyright and consequently
the GPL does not reach.  If Emacs now provided functionality using Clang
that has been intentionally omitted from or restricted in GCC, this
would be self-defeating.

So yes, in that respect GCC _does_ determine the least upper bound of
functionality.  This has by far been the most heatedly debated influence
of GPL-supporting strategic decisions on this mailing list in the last
years and has even be covered in "Linux Weekly News" several times
(searching for "Emacs" in their archives will likely pull up
references).  The way to make progress in such areas may thus be the
most frustrating part of Emacs maintainership as it requires pushing for
changes with GCC in lockstep, and in this case not just functional
changes (which already provide a challenge and thus can be expected to
move forward rather slower than faster) but also strategic direction
changes.

If you want to go there, it might be an idea starting with the
Ada-specific GCC fork which probably went under the radar with its
option exporting the parse tree.  Working on a good proof-of-concept
using that is probably the most convincing argument you can make.

The good news is likely that this is about the most you can expect in
the area of influence of the GPL and associated policies on Emacs, so if
you make yourself acquainted with the happenings there, you have seen
the practical side of the limitations due to licensing.

-- 
David Kastrup

Re: New maintainer

[Karl Fogel]

"John Wiegley" <johnw@newartisans.com> writes:
>I interpret him as meaning that the support should not favor non-GCC compilers
>in any way, not that GCC should determine the least upper bound on
>functionality.

Just to confirm what others have pointed out:

Given the context and past discussions, I think you would better assume that Richard meant "If GCC doesn't *actually* support the feature, then Emacs shouldn't add support for that feature just because Clang does."  I think at the very least the criterion would be that an actual patch to GCC must exist, even if no release of GCC includes it yet.  

That's just a guess though.  It's an open question whether the requirement would be that the FSF version (i.e., what we would call the "official" version) of GCC must support the feature, or whether it would be sufficient for the feature to be supported in a publicly available patch to GCC.  I hope the latter, since that's exactly the point at which Emacs's corresponding support would no longer be merely "theoretical" with respect to GCC.

> Isn't crippling the output of GCC, to prevent use by proprietary
> vendors, a direct example of limiting *our* freedom, as users who want
> access to that information to improve our use of Emacs (or other
> tools)? Making such information available does not make GCC or Emacs
> in any way more proprietary or freedom-destroying. If anything, it is
> liberating the information known to these applications, so that it can
> be more widely applied.

What one group chooses to do to their copy of a free software program can *never* interfere with others' freedom w.r.t. that program, because those others are always free to do whatever they want with their own copy.  If the FSF chooses not to add a feature to GCC, that doesn't interfere with your freedom.  It may interfere with your convenience, but respecting people's freedom does not require supplying them exactly the thing they want, it merely requires not interfering with their ability to procure what they want by whatever means are available to them.

The FSF can't "cripple" GCC.  It can only cripple *its version* of GCC.  You and anyone else are free to make a non-crippled version of GCC, and that's what freedom means :-).

Best,
-Karl

Re: New maintainer

[David Kastrup]

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

> "John Wiegley" <johnw@newartisans.com> writes:
>>I interpret him as meaning that the support should not favor non-GCC compilers
>>in any way, not that GCC should determine the least upper bound on
>>functionality.
>
> Just to confirm what others have pointed out:
>
> Given the context and past discussions, I think you would better
> assume that Richard meant "If GCC doesn't *actually* support the
> feature, then Emacs shouldn't add support for that feature just
> because Clang does."  I think at the very least the criterion would be
> that an actual patch to GCC must exist, even if no release of GCC
> includes it yet.
>
> That's just a guess though.  It's an open question whether the
> requirement would be that the FSF version (i.e., what we would call
> the "official" version) of GCC must support the feature, or whether it
> would be sufficient for the feature to be supported in a publicly
> available patch to GCC.  I hope the latter, since that's exactly the
> point at which Emacs's corresponding support would no longer be merely
> "theoretical" with respect to GCC.

I should think that the requirement would be that the patch would be
acceptable into the FSF version.  Reasons for non-acceptance would be a
lack of copyright assignment, or a mismatch with FSF policies.

It's really not speculative how this pans out: just look up the recent
GCC/AST/Smartcompletion spat on the Emacs developer list.

-- 
David Kastrup

Re: New maintainer

[John Wiegley]

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

> Given the context and past discussions, I think you would better assume that
> Richard meant "If GCC doesn't *actually* support the feature, then Emacs
> shouldn't add support for that feature just because Clang does." I think at
> the very least the criterion would be that an actual patch to GCC must
> exist, even if no release of GCC includes it yet.

OK, there are a few details here, and I'm hoping Richard will clarify. Let's
assume some feature X that one might want of a compiler. There are a few ways
GCC might relate to this feature:

  1. It has X, and we can expose it to Emacs.
  2. It has X, but does not provide it in a useful way, because doing so is
     against FSF policy.
  3. It could have X, but doesn't yet.
  4. It will never have X, since providing it would be prohibitively
     expensive, or against policy.

The question is, assuming Clang falls into first category, what is the
situation for Emacs?

  A. Emacs is only allowed to provide the feature for GCC, and must wait until
     GCC makes it available (if ever).

  B. Emacs can only offer the feature for other compilers too, but only once
     it is able to offer it for GCC. This means we are blocked on GCC
     development before we can support other compilers.

  C. If Emacs can support the feature in a _general_ fashion -- so that GCC
     could just as easily be supported as Clang -- then Clang support is
     allowed before GCC support, assuming Clang has it and GCC doesn't (or
     might never).

  D. Emacs is allowed to directly support Clang features that GCC never will,
     because this makes Emacs a better editor.

I'm pretty sure D is out, based on RMS' past comments. I also think A is out.
My question is whether Emacs project policy is B, C, or something more.

John

Re: New maintainer

[Karl Fogel]

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

On Tue, Oct 6, 2015 at 5:59 PM, John Wiegley <johnw@newartisans.com> wrote:

>   A. Emacs is only allowed to provide the feature for GCC, and must wait
> until
>      GCC makes it available (if ever).
>
>   B. Emacs can only offer the feature for other compilers too, but only
> once
>      it is able to offer it for GCC. This means we are blocked on GCC
>      development before we can support other compilers.
>
>   C. If Emacs can support the feature in a _general_ fashion -- so that GCC
>      could just as easily be supported as Clang -- then Clang support is
>      allowed before GCC support, assuming Clang has it and GCC doesn't (or
>      might never).
>
>   D. Emacs is allowed to directly support Clang features that GCC never
> will,
>      because this makes Emacs a better editor.
>
> I'm pretty sure D is out, based on RMS' past comments. I also think A is
> out.
> My question is whether Emacs project policy is B, C, or something more.


I believe it is (B).

Best,
-K

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

Re: New maintainer

[Phillip Lord]

John Wiegley <johnw@newartisans.com> writes:
> The question is, assuming Clang falls into first category, what is the
> situation for Emacs?
>
>   A. Emacs is only allowed to provide the feature for GCC, and must wait until
>      GCC makes it available (if ever).
>
>   B. Emacs can only offer the feature for other compilers too, but only once
>      it is able to offer it for GCC. This means we are blocked on GCC
>      development before we can support other compilers.
>
>   C. If Emacs can support the feature in a _general_ fashion -- so that GCC
>      could just as easily be supported as Clang -- then Clang support is
>      allowed before GCC support, assuming Clang has it and GCC doesn't (or
>      might never).
>
>   D. Emacs is allowed to directly support Clang features that GCC never will,
>      because this makes Emacs a better editor.
>
> I'm pretty sure D is out, based on RMS' past comments. I also think A is out.
> My question is whether Emacs project policy is B, C, or something more.

It's worth mentioning that we have been through all of this before. More
over there was a very clear difference of opinion between Richard and
the current (if retiring) Emacs maintainer.

https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00498.html
https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00171.html

If I may be so bold as to speak for Richard and Stefan the answers were
B and D respectively.

I mention this not to stir up old arguments, but simply to point out
that these arguments have not been resolved in the past. While I am
hopeful that they will be resolved in the future, I suspect that trying
to sort this issue out now is a side-track, which should not block
discussion of the maintainership.

Phil

Re: New maintainer

[John Wiegley]

>>>>> Phillip Lord <phillip.lord@russet.org.uk> writes:

> I mention this not to stir up old arguments, but simply to point out that
> these arguments have not been resolved in the past. While I am hopeful that
> they will be resolved in the future, I suspect that trying to sort this
> issue out now is a side-track, which should not block discussion of the
> maintainership.

I realize we're on the 1000th round of this discussion, but I've not been
directly involved in it before, and it has a direct bearing on my willingness
to maintain Emacs.

Guiding a project's technical future requires devotion and enthusiasm, and a
certain degree of freedom. If the directions I want to take Emacs in are going
to be consistently hampered by the "needs of freedom", this will cause me to
lose all such energy.

I'm going be the one at conferences, talking to users, saying, "Yes, we know;
yes, it's a great idea; yes, it should be there; yes, I even want to do it
myself, yesterday; but talk to me in ten years when GCC has gotten around to
providing what we need."

I'm beginning to think GNU Emacs will need someone who also cares about the
freedom argument first, and the technical needs second, because I'm very much
concerned I would chomping at the bit to move forward, and unable to for
reasons I don't necessarily agree with.

John

Re: New maintainer

[Phillip Lord]

John Wiegley <johnw@newartisans.com> writes:

>>>>>> Phillip Lord <phillip.lord@russet.org.uk> writes:
>
>> I mention this not to stir up old arguments, but simply to point out that
>> these arguments have not been resolved in the past. While I am hopeful that
>> they will be resolved in the future, I suspect that trying to sort this
>> issue out now is a side-track, which should not block discussion of the
>> maintainership.
>
> I realize we're on the 1000th round of this discussion, but I've not been
> directly involved in it before, and it has a direct bearing on my willingness
> to maintain Emacs.
>
> Guiding a project's technical future requires devotion and enthusiasm, and a
> certain degree of freedom. If the directions I want to take Emacs in are going
> to be consistently hampered by the "needs of freedom", this will cause me to
> lose all such energy.

Yes, that is a possibility indeed. To be honest, though, I think the
"consistently hampered" concerns is misplaced. In fact, the GCC argument
came about because of (Richard's) interpretation of the needs of freedom
wrt GCC, rather than Emacs per se.

From my own perspective, as a very long term Emacs user, the issue
doesn't impact me directly because I don't write very much C or use
either GCC or clang (as dev tools -- obviously I build with them).

My own take on the issue, though, is that worrying now about what *may*
cause you to lose energy in the future is self-defeating. I hope that
you take up the role, I think that you will bring energy to it, and I
hope that you find it to be a rewarding and valuable experience.


> I'm going be the one at conferences, talking to users, saying, "Yes, we know;
> yes, it's a great idea; yes, it should be there; yes, I even want to do it
> myself, yesterday; but talk to me in ten years when GCC has gotten around to
> providing what we need."
>
> I'm beginning to think GNU Emacs will need someone who also cares about the
> freedom argument first, and the technical needs second, because I'm very much
> concerned I would chomping at the bit to move forward, and unable to for
> reasons I don't necessarily agree with.

I don't think that this is the case. It's just the case that the moral
discussions raise more noise than the technical ones, simply because
more people know about something about them.

For instance, while this (long) thread has been happening, Stefan has
been his useful helpful self in helping me with a small change to the
undo system. In total, that's resulted in maybe 10 emails over a month,
compared to the 10 emails an hour on the ethics of exposing GCC/clang
ASTs. The evolution of Emacs is affected as much, I think, by
combination of these small changes as anything.

In short, I wouldn't judge the needs of Emacs by the volume of email.
And, in an attempt to not add to that volume, I shall say no more on
this thread, other than to wish any future maintainer(s) luck whoever
they may be.

Phil

Re: New maintainer

[David Kastrup]

"John Wiegley" <johnw@newartisans.com> writes:

>>>>>> Phillip Lord <phillip.lord@russet.org.uk> writes:
>
>> I mention this not to stir up old arguments, but simply to point out that
>> these arguments have not been resolved in the past. While I am hopeful that
>> they will be resolved in the future, I suspect that trying to sort this
>> issue out now is a side-track, which should not block discussion of the
>> maintainership.
>
> I realize we're on the 1000th round of this discussion, but I've not been
> directly involved in it before, and it has a direct bearing on my willingness
> to maintain Emacs.
>
> Guiding a project's technical future requires devotion and enthusiasm, and a
> certain degree of freedom. If the directions I want to take Emacs in are going
> to be consistently hampered by the "needs of freedom", this will cause me to
> lose all such energy.
>
> I'm going be the one at conferences, talking to users, saying, "Yes, we know;
> yes, it's a great idea; yes, it should be there; yes, I even want to do it
> myself, yesterday; but talk to me in ten years when GCC has gotten around to
> providing what we need."

No, that will not be the case.  "when GCC has gotten around to providing
what we need" suggests that GCC is holding things up.  They are equally
"stomping at the bits", meaning that there have been previous attempts
of writing out the annotated syntax tree or similarly generally useful
stuff that could feed other functionality based on GCC but not falling
under the GPL with regard to "the whole work" criterion because of using
a generic interface.

So for developing this kind of functionality in lockstep with GCC
developers using specialized (namely non-generic) interfaces, you'll
likely find a path leading forward.  The more generally useful such
interfaces will get, the more it will require seeking for an adaption of
FSF policies to the realities you are eager to create.

You won't be turning this ship on a dime.  But I also don't think that
it wouldn't budge when you try getting the pieces in place.  But the
pieces would have to start with working with GCC developers and Richard
open-ended on the kind of needed functionality rather than being based
off Clang's existing state.

> I'm beginning to think GNU Emacs will need someone who also cares
> about the freedom argument first, and the technical needs second,
> because I'm very much concerned I would chomping at the bit to move
> forward, and unable to for reasons I don't necessarily agree with.

As I said: I don't think you'll be unable to move forward but you'll
need to coordinate that movement with the other horses in the equipage
(sorry, your analogy).

-- 
David Kastrup

Re: New maintainer

[Stephen J. Turnbull]

John Wiegley writes:

 > I'm beginning to think GNU Emacs will need someone who also cares
 > about the freedom argument first, and the technical needs second,
 > because I'm very much concerned I would chomping at the bit to move
 > forward, and unable to for reasons I don't necessarily agree with.

I wouldn't worry about that if I were you.  The principle itself
bothers me a heck of a lot more than the exercise of it does.

In the twenty years I've been following Emacs development, I can
remember only four occasions where Richard has deliberately sacrificed
significant improvements to Emacs in the name of promoting either
software freedom or the GNU Project: TRAMP, Bazaar, DSOs, and now use
of the AST exported by LLVM.

Of course, the TRAMP mistake has long since been corrected, and the
Bazaar fiasco is a thing of the past.  The no-DSO policy has been
rescinded recently, and work is actively proceeding on adding that
feature.  LLVM?  "This, too, will pass."

Bottom line: just thinking about it is frustrating, yes, but
"consistently hampered" (your words) in getting work done?  No.

Re: New maintainer

[David Kastrup]

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

> John Wiegley writes:
>
>  > I'm beginning to think GNU Emacs will need someone who also cares
>  > about the freedom argument first, and the technical needs second,
>  > because I'm very much concerned I would chomping at the bit to move
>  > forward, and unable to for reasons I don't necessarily agree with.
>
> I wouldn't worry about that if I were you.  The principle itself
> bothers me a heck of a lot more than the exercise of it does.
>
> In the twenty years I've been following Emacs development, I can
> remember only four occasions where Richard has deliberately sacrificed
> significant improvements to Emacs in the name of promoting either
> software freedom or the GNU Project: TRAMP, Bazaar, DSOs, and now use
> of the AST exported by LLVM.
>
> Of course, the TRAMP mistake has long since been corrected, and the
> Bazaar fiasco is a thing of the past.  The no-DSO policy has been
> rescinded recently, and work is actively proceeding on adding that
> feature.  LLVM?  "This, too, will pass."

To put more precision to it: usually the point of time where the
strategy changes is when it has become pointless.  Since LLVM already
outputs annotated syntax trees, blocking GCC from that kind of
interoperation is not going to achieve a useful purpose for the GNU
project at the current point of time.

So I don't expect that restriction to stick around for all that much
longer in the current form: after all, we don't have anything to gain
from people putting LLVM into their applications rather than GCC even if
we had preferred such applications to fall under the GPL because of
tight integration with GCC.

-- 
David Kastrup

Re: New maintainer

[Stephen J. Turnbull]

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

 > > LLVM?  "This, too, will pass."
 > 
 > To put more precision to it: usually the point of time where the
 > strategy changes is when it has become pointless.

I don't think that's true.  First of all, all of the examples I
mentioned were considered pointless when first implemented, except to
satisfy Richard's extreme risk aversion.  Nobody else could see any
danger to compare to the gain.  Second, history says otherwise.

- TRAMP: added when free SSHv2 became available.  (Today, lsh is a
  logical operator, not a secure shell.)

- Bazaar: abandoned when it became clear that not only was it GNU in
  name only, it was a project in name only, and annoying (admittedly,
  not crippling) bugs continued to surface and not be fixed.
  Unfamiliarity with it and distaste for its opinionated approach to
  VC were genuine barriers to new contributors (not terribly high, but
  more real than any danger cited in support of these policies).

- DSOs: permitted when the leagle eagles OK'ed the strategy
  (ironically, originated by the Linux kernel IIRC) of requiring a
  call to a "I am licensed under GPL" API before enabling a module for
  GCC, and Richard judged that the same arguments applied to Emacs.

 > Since LLVM already outputs annotated syntax trees, blocking GCC
 > from that kind of interoperation is not going to achieve a useful
 > purpose for the GNU project at the current point of time.

I agree, as I'm sure you already guessed, but here Richard isn't
concerned with useful purposes, he worries that part of GCC itself can
be suborned by a proprietary system.  Currently RTL and the like are
*internal* formats that can be saved to disk, but they are not "data"
that is output to be consumed by *arbitrary* other Works (in the
copyright sense), and therefore exempt from the GPL, which (as a bare
license) can make no restriction on how you use the data output from a
program.  They're internal data structures, subject to copyright even
though produced by a program, that happen to reside on disk rather
than in memory.  IIUC, this principle was tested in the NeXT (Apple?) 
Objective C case and found dependable (enough).

So GCC is is directly constrained, but this has a knock-on effect on
Emacs because support for this feature provided by LLVM would give
LLVM-based development a competitive advantage over GCC-based
development, so support is (for now) prohibited.

 > So I don't expect that restriction to stick around for all that
 > much longer in the current form: after all, we don't have anything
 > to gain from people putting LLVM into their applications rather
 > than GCC even if we had preferred such applications to fall under
 > the GPL because of tight integration with GCC.

That was true when Richard announced that he was putting this idea on
hold while he studied the technical and legal aspects of outputting
CAST[1] so that Emacs can use it but even GCC's own backend can't
consume it.  I think you misunderstand the strength of his
determination not to yield a nanometer to proprietary software.

I believe that, from John's point of view, the risk is real that
Richard will indeed insist on CAST, which will hamper attempts to
extend use of compiler-generated ASTs from completion (or whatever the
initial application is) to refactoring and so on, miring them in
further discussions of the kind that happened earlier for every
extension.

I do, however, want to emphasize that this kind of prior restraint on
Emacs development is *extremely* rare.

Footnotes: 
[1]  Crippled Annotated Syntax Trees.

Re: New maintainer

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I'm beginning to think GNU Emacs will need someone who also cares about the
  > freedom argument first, and the technical needs second, because I'm very much
  > concerned I would chomping at the bit to move forward, 

It's a question of which direction is "forward".
I want to move forward on the GNU Project, of which GNU Emacs
is a part.

Most of the time, making Emacs better to use is exactly the way Emacs
can move the GNU Project forward, but once in a rare while there's an
exception.  Someone posted a list of four cases that have occurred
in GNU Emacs over three decades.


-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: New maintainer

[Dmitry Gutov]

On 10/05/2015 11:16 PM, Jay Belanger wrote:

> That's the point.  It sounded like Richard was saying that in that case,
> Emacs shouldn't take advantage of it.  How else could

Right. Since the GCC support would only be "theoretical".

>> If it really works usefully with GCC -- if that is not just a theoretical
>> idea -- then I won't object to its supporting other compilers as well.
>
> be interpreted?

Works usefully with GCC *now*, or whenever the feature in question is 
introduced.

While I personally disagree with that stance, it's good to understand 
clearly the current state of this issue.

Re: New maintainer

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Any solution we choose should never preclude the opportunity for GCC to
  > outshine other choices.

That's true, but it is too weak; we are failing to communicate.  The
issue is not about what is "precluded" but rather about what actually
works.  The point is, when the feature is introduced in Emacs, it
should really work with GCC as well as it does with any competitor to
GCC.

What I want to avoid is that Emacs starts encouraging people to switch
from GCC to some competitor.

This issue is not about free vs proprietary software.  I am not saying
that competitors to a GNU package are unjust or bad -- that isn't
necessarily so.  The pertinent point is that they are _competitors_.
The goal if the GNU Project is for GNU to win the competition.  Each
GNU package is a part of the GNU system, and should contribute to the
success of the GNU Project.

Thus, each GNU package should encourage people to run other GNU
packages rather than their competitors -- even competitors which are
free software.

This is a practical question.  It's about practical effect, not some
legalistic criterion.

Thus, it wouldn't be good enough if there is a GCC patch we don't
endorse, that makes it do the job in question -- because, practically
speaking, that wouldn't change the effect much.  The support should be
in the real GCC sources.

On the other hand, it would be good enough for that to be in the
development GCC repository in the master or root.  We don't need to
wait for it to be officially released.


-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: New maintainer

[John Wiegley]

>>>>> Richard Stallman <rms@gnu.org> writes:

> That's true, but it is too weak; we are failing to communicate. The issue is
> not about what is "precluded" but rather about what actually works. The
> point is, when the feature is introduced in Emacs, it should really work
> with GCC as well as it does with any competitor to GCC.

Hi Richard,

Thank you for the clarification, the picture is becoming much clearer. I
really appreciate the time you've taken to reiterate these positions for the
millionth time.

There is one point I am having a hard time with. I'm feeling as though my
Emacs experience (as a user) is being sacrificed at someone else's altar.

The idea, if I understand it, is that you don't want Emacs' C++ support to
allow Clang to beat GCC, because then people would naturally choose Clang who
care more about getting things done, than they do about software freedom. In
effect, Emacs is being used to keep people within the free software agenda, by
making Clang no more appealing than GCC.

This troubles me. I can see that for you, the freedom idea is much more
important than the technical idea. You'd rather we stick with GCC until the
cows come home, so long as it leads to a freer world.

Meanwhile, there are those among us who don't share your ideals to the same
extent. We'd prefer an editor that lets us get things done faster, better,
leaving us with free time to... produce more free software.

I can't help but think that unless the FSF has more to offer than its ideals,
its technical decisions are going to render it obsolete. Progress waits for no
man, and the world is changing more and more rapidly. There is a reason Clang
is eating GCC's lunch: because the needs of a larger community demand a better
free compiler.

Emacs is still a fantastic editor, but it's old and its age is showing. If we
remain competitive, it could stay awesome for another 30 years; but if we
avoid progress to further non-technical agendas, I think it will drive people
AWAY from the GNU project, not bind them more tightly to it.

John

Re: New maintainer

[David Kastrup]

John Wiegley <johnw@newartisans.com> writes:

> I can't help but think that unless the FSF has more to offer than its
> ideals, its technical decisions are going to render it obsolete.

The FSF never had substantially more to offer than its ideals.  All the
rest has been provided by volunteers and donations.  While Richard has
thrown a substantial amount of his own work and money and time into it
at the start, in the overall scheme that's not much more than a
catalyst.

> Progress waits for no man, and the world is changing more and more
> rapidly. There is a reason Clang is eating GCC's lunch: because the
> needs of a larger community demand a better free compiler.

The FSF has no control over the direction of Clang, technical or with
regard to licensing.  A whole lot of software is "eating GNU's lunch" in
a number of technical categories.  GNU started out with everybody
"eating its lunch".  The mission of the GNU project is to provide a
coherent whole with freedoms that cannot be subverted.

Apple's XCode environment is based on a free compiler, Clang, but is
licensed in a way where you may not run it on anything but Apple
computers.  _That's_ how you really eat the lunch of free software.
Having Emacs integrate with XCode for developing code in a manner that
cannot be done with the GNU system would be self-defeating.

It's the point of the GPL to be hard to subvert against the cause of
free software.  But the GPL is not a philosophical authority but a legal
tool.  Software licensed under it can be used according to our goals or
against them.  Where the only uses are weakening our cause, there is no
point in being the front-runner.  Everybody may fork Emacs (or just
provide his own packages) who wants to work on goals not helping the GNU
project, but there is no point in the core of Emacs relying on resources
and the blessing of the FSF to do so.

> Emacs is still a fantastic editor, but it's old and its age is
> showing. If we remain competitive, it could stay awesome for another
> 30 years; but if we avoid progress to further non-technical agendas, I
> think it will drive people AWAY from the GNU project, not bind them
> more tightly to it.

That argument is more than 30 years old, and many parts of the GNU
project have taken second place to other software a whole lot of the
time.  But the front leaders wither and die and get replaced by others.
GNU sticks around.  Emacs sticks around.  Its largest traditional
competitor is "vi" and it is factually gone, replaced by the most
popular free vi clone of the decade (currently vim).

Yes, we'll not end up in first place on technical merit lots of the time
because ending up in first place is not the first priority.  The first
priority is to provide a free cohesive system with essential parts
nominally and effectively under the GPL so that its use as a building
block will lead to more systems honoring and providing software freedom.

Taking custody of that may be a nuisance if you don't care or even
disagree.  But even though it's an essential part of the job, it should
not turn out a permanent distraction.  And if it does, one should try
finding a solution or compromise that manages to serve the conflicting
priorities better.

-- 
David Kastrup

Re: New maintainer

[joakim]

David Kastrup <dak@gnu.org> writes:

> John Wiegley <johnw@newartisans.com> writes:
>
>> I can't help but think that unless the FSF has more to offer than its
>> ideals, its technical decisions are going to render it obsolete.
>
> The FSF never had substantially more to offer than its ideals.  All the
> rest has been provided by volunteers and donations.  While Richard has
> thrown a substantial amount of his own work and money and time into it
> at the start, in the overall scheme that's not much more than a
> catalyst.
>
>> Progress waits for no man, and the world is changing more and more
>> rapidly. There is a reason Clang is eating GCC's lunch: because the
>> needs of a larger community demand a better free compiler.
>
> The FSF has no control over the direction of Clang, technical or with
> regard to licensing.  A whole lot of software is "eating GNU's lunch" in
> a number of technical categories.  GNU started out with everybody
> "eating its lunch".  The mission of the GNU project is to provide a
> coherent whole with freedoms that cannot be subverted.
>
> Apple's XCode environment is based on a free compiler, Clang, but is
> licensed in a way where you may not run it on anything but Apple
> computers.  _That's_ how you really eat the lunch of free software.
> Having Emacs integrate with XCode for developing code in a manner that
> cannot be done with the GNU system would be self-defeating.

As I sometimes get bitten by this in my day job, I would just like to
add that a lot of people I meet that are not even interested in free
software, find this aspect of the Apple development stack appalling.

While this is not my personal position, you can use the GNU tools and
not really care about the freedom, but you still benefit from it. You
can use free software library and all you need to do is provide the
source for your users. You can deploy code like this with no worries, as
long as you comply with the GPL, which isn't really hard.

Then when you are writing, say, an ios client, the situation is
different. The developers I work with quite often don't think that Apple
software is especially fascinating. Still, they can't choose not to use Apple
tools in the build chain. You have to have Apple hardware, which isn't
suitable in a datacenter. You can't choose to not use Xcode and
whatever.

With this I just wanted to add another datapoint.  


>
> It's the point of the GPL to be hard to subvert against the cause of
> free software.  But the GPL is not a philosophical authority but a legal
> tool.  Software licensed under it can be used according to our goals or
> against them.  Where the only uses are weakening our cause, there is no
> point in being the front-runner.  Everybody may fork Emacs (or just
> provide his own packages) who wants to work on goals not helping the GNU
> project, but there is no point in the core of Emacs relying on resources
> and the blessing of the FSF to do so.
>
>> Emacs is still a fantastic editor, but it's old and its age is
>> showing. If we remain competitive, it could stay awesome for another
>> 30 years; but if we avoid progress to further non-technical agendas, I
>> think it will drive people AWAY from the GNU project, not bind them
>> more tightly to it.
>
> That argument is more than 30 years old, and many parts of the GNU
> project have taken second place to other software a whole lot of the
> time.  But the front leaders wither and die and get replaced by others.
> GNU sticks around.  Emacs sticks around.  Its largest traditional
> competitor is "vi" and it is factually gone, replaced by the most
> popular free vi clone of the decade (currently vim).
>
> Yes, we'll not end up in first place on technical merit lots of the time
> because ending up in first place is not the first priority.  The first
> priority is to provide a free cohesive system with essential parts
> nominally and effectively under the GPL so that its use as a building
> block will lead to more systems honoring and providing software freedom.
>
> Taking custody of that may be a nuisance if you don't care or even
> disagree.  But even though it's an essential part of the job, it should
> not turn out a permanent distraction.  And if it does, one should try
> finding a solution or compromise that manages to serve the conflicting
> priorities better.

-- 
Joakim Verona

Re: New maintainer

[Karl Fogel]

John, your points below are a continuation of a very interesting tactical (and philosophical) debate... that was already held on this list fairly recently, and that eventually went somewhat off-topic for this list even then :-).

While the questions you raise are worth discussing for the GNU project as a whole, I think Richard has made it clear that the position of the FSF regarding Emacs' development priorities is definitely not going to be changed as part of this new maintainer discussion.

So if at this point you were to say that, as far as being an Emacs maintainer goes, you understand and are willing to abide by the priorities Richard has articulated, even though you disagree with them, that would settle an important question.  Or if you don't think you can abide by them, in your work as maintainer, that would be useful to know too (though it would probably result in you not being the maintainer).

As you know, I hope you can abide by them and be the maintainer (or a co-maintainer) because I think you'd be terrific at it.  But it's your call.  I merely urge clarity; Richard has made his position clear, so if you do too then things can move forward one way or the other.

Best,
-K

John Wiegley <johnw@newartisans.com> writes:
>Hi Richard,
>
>Thank you for the clarification, the picture is becoming much clearer. I
>really appreciate the time you've taken to reiterate these positions for the
>millionth time.
>
>There is one point I am having a hard time with. I'm feeling as though my
>Emacs experience (as a user) is being sacrificed at someone else's altar.
>
>The idea, if I understand it, is that you don't want Emacs' C++ support to
>allow Clang to beat GCC, because then people would naturally choose Clang who
>care more about getting things done, than they do about software freedom. In
>effect, Emacs is being used to keep people within the free software agenda, by
>making Clang no more appealing than GCC.
>
>This troubles me. I can see that for you, the freedom idea is much more
>important than the technical idea. You'd rather we stick with GCC until the
>cows come home, so long as it leads to a freer world.
>
>Meanwhile, there are those among us who don't share your ideals to the same
>extent. We'd prefer an editor that lets us get things done faster, better,
>leaving us with free time to... produce more free software.
>
>I can't help but think that unless the FSF has more to offer than its ideals,
>its technical decisions are going to render it obsolete. Progress waits for no
>man, and the world is changing more and more rapidly. There is a reason Clang
>is eating GCC's lunch: because the needs of a larger community demand a better
>free compiler.
>
>Emacs is still a fantastic editor, but it's old and its age is showing. If we
>remain competitive, it could stay awesome for another 30 years; but if we
>avoid progress to further non-technical agendas, I think it will drive people
>AWAY from the GNU project, not bind them more tightly to it.
>
>John

Re: New maintainer

[John Wiegley]

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

> So if at this point you were to say that, as far as being an Emacs
> maintainer goes, you understand and are willing to abide by the priorities
> Richard has articulated, even though you disagree with them, that would
> settle an important question. Or if you don't think you can abide by them,
> in your work as maintainer, that would be useful to know too (though it
> would probably result in you not being the maintainer).

I'm pretty sure that if it came up in a significant way, I wouldn't be able to
stand by it. The insistence on Bazaar over Git, for example, caused me to stop
contributing to Emacs a few years back. And I've been unhappy about the DSO
situation since around 1999. Very glad to see these two getting resolved!

What I wonder is whether Richard and I could reach a compromise if it happens
while we're working together. I'm not saying everything has to go my way; but
if I see something that needs to happen for the sake of users, would we be
able to find an alternate path? I'm not sure this can be answered in a mailing
list thread. It depends on what rapport develops between me and the FSF.

I'll be in the Boston area at the beginning of December; I'd like to stop by
the offices of the FSF, and sit down with Richard to talk about these things
face to face. That would answer more for me than any amount of debate.

If that timeframe is too long for a decision, I'm willing to help out Emacs
until it becomes a real problem. There are plenty of areas where no
disagreement exists at all.

John

Re: New maintainer

[David Kastrup]

"John Wiegley" <johnw@newartisans.com> writes:

> I'll be in the Boston area at the beginning of December; I'd like to
> stop by the offices of the FSF, and sit down with Richard to talk
> about these things face to face. That would answer more for me than
> any amount of debate.

I consider that an excellent idea.

-- 
David Kastrup

Re: New maintainer

[Eli Zaretskii]

> From: "John Wiegley" <johnw@newartisans.com>
> Date: Thu, 08 Oct 2015 17:14:02 -0700
> 
> >>>>> Karl Fogel <kfogel@red-bean.com> writes:
> 
> > So if at this point you were to say that, as far as being an Emacs
> > maintainer goes, you understand and are willing to abide by the priorities
> > Richard has articulated, even though you disagree with them, that would
> > settle an important question. Or if you don't think you can abide by them,
> > in your work as maintainer, that would be useful to know too (though it
> > would probably result in you not being the maintainer).
> 
> I'm pretty sure that if it came up in a significant way, I wouldn't be able to
> stand by it. The insistence on Bazaar over Git, for example, caused me to stop
> contributing to Emacs a few years back. And I've been unhappy about the DSO
> situation since around 1999. Very glad to see these two getting resolved!

It's too bad, IMO, that you evidently assign so much importance to
issues with which you disagree.  Cooperation is about finding the
areas of agreement, which are certainly vast in this case, and using
them for the common good, rather than poking at the few disagreements.

> What I wonder is whether Richard and I could reach a compromise if it happens
> while we're working together. I'm not saying everything has to go my way; but
> if I see something that needs to happen for the sake of users, would we be
> able to find an alternate path?

It's a question no one will be able to answer in advance.  These
issues are decided on a case by case basis, depending on the balance
of advantages and disadvantages in each specific case.  Sometimes your
suggestion could be accepted even without a compromise, sometimes
there could be a compromise, and sometimes no compromise will be
possible.

You will have to decide up front whether a possibility of no
compromise in some situations is something you will be able to live
with.  This is something that IMO sheds light not only on your
relations with Richard and the FSF, but also on your relations with
other contributors here, because such situations will arise there as
well.

> If that timeframe is too long for a decision, I'm willing to help out Emacs
> until it becomes a real problem. There are plenty of areas where no
> disagreement exists at all.

Exactly.  And my question is: why not concentrate on those areas, and
simply "bypass" (a.k.a. "ignore") the rest?

Re: New maintainer

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> It's too bad, IMO, that you evidently assign so much importance to issues
> with which you disagree. Cooperation is about finding the areas of
> agreement, which are certainly vast in this case, and using them for the
> common good, rather than poking at the few disagreements.
> 
> You will have to decide up front whether a possibility of no compromise in
> some situations is something you will be able to live with. This is
> something that IMO sheds light not only on your relations with Richard and
> the FSF, but also on your relations with other contributors here, because
> such situations will arise there as well.
> 
> [...] And my question is: why not concentrate on those areas, and simply
> "bypass" (a.k.a. "ignore") the rest?

Eli, the time I have free to spend on open source projects is very limited,
and extremely precious to me. There are a hundred more things I want to do,
than can do, on any given day. So to make a commitment of this extent, I must
be confident in what I'm getting myself into. Not just the technical content,
or even the political content, but the "spirit" of those who are in charge of
decisions that could make my life as a contributor miserable, should they
choose.

My questions are somewhat pinpointed in this thread, because I'm using them to
bring out characteristics from people that I can't determine just by asking
their friendly opinions. I've been extremely impressed with Richard throughout
this transaction, and frankly that has mattered more to me than anything
that's been said. Seeing how a thread progresses when an issue is put under a
microscope like this, tells me more about the community than it does about the
issue. The issue itself, in fact, has only become greyer -- as often happens
-- since I'm coming to appreciate the complexities of the problem.

Once I have faith, I do "ignore" the rest, and you won't have to worry about
me arguing every point. But if you do worry, then vote -1, and I'll completely
understand.

John

Re: New maintainer

[Eli Zaretskii]

> From: John Wiegley <johnw@newartisans.com>
> Date: Fri, 09 Oct 2015 10:25:36 -0700
> 
> >>>>> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > It's too bad, IMO, that you evidently assign so much importance to issues
> > with which you disagree. Cooperation is about finding the areas of
> > agreement, which are certainly vast in this case, and using them for the
> > common good, rather than poking at the few disagreements.
> > 
> > You will have to decide up front whether a possibility of no compromise in
> > some situations is something you will be able to live with. This is
> > something that IMO sheds light not only on your relations with Richard and
> > the FSF, but also on your relations with other contributors here, because
> > such situations will arise there as well.
> > 
> > [...] And my question is: why not concentrate on those areas, and simply
> > "bypass" (a.k.a. "ignore") the rest?
> 
> Eli, the time I have free to spend on open source projects is very limited,
> and extremely precious to me. There are a hundred more things I want to do,
> than can do, on any given day.

Same here.

> So to make a commitment of this extent, I must be confident in what
> I'm getting myself into. Not just the technical content, or even the
> political content, but the "spirit" of those who are in charge of
> decisions that could make my life as a contributor miserable, should
> they choose.

All understandable and agreed.  I have no problem with the questions
you ask.  I just responded to one specific thing you wrote that is not
a question at all:

> I'm pretty sure that if it came up in a significant way, I wouldn't be able to
> stand by it.

That's pretty black-and-white, no gray areas there.  I do hope that
this kind of confrontation will happen less in Emacs development than
it happened until now.  Maybe I'm naïve.

Re: New maintainer

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

>> I'm pretty sure that if it came up in a significant way, I wouldn't be able
>> to stand by it.

> That's pretty black-and-white, no gray areas there. I do hope that this kind
> of confrontation will happen less in Emacs development than it happened
> until now. Maybe I'm naïve.

I'm willing to hope right along with you. :) There are some decisions I can't
brook, but based on what I've seen from everyone here, I'm becoming more and
more hopeful that it won't ever be a real problem.

John

Re: New maintainer

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > What I wonder is whether Richard and I could reach a compromise if
  > it happens while we're working together. I'm not saying everything
  > has to go my way; but if I see something that needs to happen for
  > the sake of users, would we be able to find an alternate path? I'm
  > not sure this can be answered in a mailing list thread. It depends
  > on what rapport develops between me and the FSF.

I think we can work together this way.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: New maintainer

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

   > Emacs is being used to keep people within the free software agenda,

Since people are free to change a free program, our decisions of what
to include or not include can't "keep" people anywhere.  The most we
can do is decide in which direction to lead people, where to
help/encourage them to go.

Of course we should develop GNU Emacs so as to support the free
software agenda.  That's been its purpose since I started it in 1984.
That's the purpose of the GNU system as a whole, too.

  > This troubles me. I can see that for you, the freedom idea is much more
  > important than the technical idea. You'd rather we stick with GCC until the
  > cows come home, so long as it leads to a freer world.

Naturally -- because I think freedom is more important than technical
progress.  Proprietary software offers plenty of technical "progress",
but since I won't surrender my freedom to use it, as far as I'm
concerned it is no progress at all.

If I had valued technical advances over freedom in 1984, instead of
developing GNU Emacs and GCC and GDB I would have gone to work for
AT&T and improved its nonfree software.  What a big head start I could
have got!

If we subordinate our freedom to technical advance, companies will
easily be able to lead us away from freedom.  Companies make
multi-year plans to part users from their freedom.  (Clang has
benefited from such a plan.)  We can't carry out plans the way
companies can, but we do need to think about where we want to end up.

  > avoid progress to further non-technical agendas, I think it will drive people
  > AWAY from the GNU project, not bind them more tightly to it.

I don't think we can enable the GNU system to succeed more by
declaring "Each package for itself!"  To stand against capable rivals
-- some of which are not merely competitors, but intentional
opposition -- GNU packages need to work and stand together.

We also need that cooperation in order to give the GNU system a better
IDE.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: New maintainer

[Tom]

Richard Stallman <rms <at> gnu.org> writes:
> 
> Naturally -- because I think freedom is more important than technical
> progress.  Proprietary software offers plenty of technical "progress",
> but since I won't surrender my freedom to use it, as far as I'm
> concerned it is no progress at all.


Then there is no sense talking about competing with IDEs. IDEs provide
cutting edge features in the areas of completion and refactoring and
most users will only choose Emacs over an IDE if it provides a
a comparable level of these features.

Most users won't switch just because of the freedom aspect. They will
switch if Emacs is at least as good in these areas as their IDEs,
so if competing is the goal then catching up with popular IDEs
technically is unaviodable.

Re: New maintainer

[David Kastrup]

Tom <adatgyujto@gmail.com> writes:

> Richard Stallman <rms <at> gnu.org> writes:
>> 
>> Naturally -- because I think freedom is more important than technical
>> progress.  Proprietary software offers plenty of technical "progress",
>> but since I won't surrender my freedom to use it, as far as I'm
>> concerned it is no progress at all.
>
> Then there is no sense talking about competing with IDEs.

Under the premise that Emacs' only user is Richard, this is not a
competition.

> IDEs provide cutting edge features in the areas of completion and
> refactoring and most users will only choose Emacs over an IDE if it
> provides a a comparable level of these features.

Emacs will rarely ever be "cutting edge" but that does not mean that
there is no point in improving it.  And the features with which
proprietary software is competing among its ilk are certainly something
worthwhile to consider for such improvement.

> Most users won't switch just because of the freedom aspect. They will
> switch if Emacs is at least as good in these areas as their IDEs, so
> if competing is the goal then catching up with popular IDEs
> technically is unaviodable.

Competing is not the goal.  Improving Emacs is.  There are a number of
areas in which Emacs is so much different than other systems that there
is no competition at all.  But that does not mean that those areas are
not worth improving for improvement's sake.

-- 
David Kastrup

Re: New maintainer

[Stephen J. Turnbull]

Tom writes:

 > Richard Stallman <rms <at> gnu.org> writes:
 > > 
 > > Naturally -- because I think freedom is more important than technical
 > > progress.  Proprietary software offers plenty of technical "progress",
 > > but since I won't surrender my freedom to use it, as far as I'm
 > > concerned it is no progress at all.
 > 
 > Then there is no sense talking about competing with IDEs. IDEs provide
 > cutting edge features in the areas of completion and refactoring and
 > most users will only choose Emacs over an IDE if it provides a
 > a comparable level of these features.

I disagree with Richard's approach to the problem of advocating
freedom.[1]

But let's not be extreme, especially not in the face of the GNU/Linux
experience.  We *can* do, we have done, the "impossible".  While Emacs
is the best at what it does, admittedly it caters to a particularly
refined taste.  But Apache and Linux prove that not only can we do the
impossible, we can do it better than well-funded corporations,
sometimes.

 > Most users won't switch just because of the freedom aspect.

True.  But so what?  A few will switch for freedom alone (eg, Richard
Stallman ;-), a few more will switch for freedom and 10% of the
proprietary alternative's functionality.  Let's see how high we can
push the comparison coefficient on functionality (without sacrificing
the freedom), and see how many come.  We all love dog food, right?


Footnotes: 
[1]  I managed to suppress the temptation to explain my viewpoint and
left only this footnote.  But I couldn't resist leaving the
footnote.... ;-)

Re: New maintainer

[Artur Malabarba]

(Back on the topic of new maintainers)

I only know John Wiegley by reputation and by code (both of which are
very good), but putting that together with the conversations on the
current topic, it looks to me like he would make a very good
maintainer.

I know Eli from many other topics on this list, and I also think he
would make a good addition to the maintainer team. My only concern
would be that the burn-out effect might cause him to cease
contributing. Eli is among our most active contributors and I shiver
in fear at the thought of losing his contributions.

Best,
Artur

Re: New maintainer

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > So I will withdraw my withdrawal, and say that if the opinions of the FSF, and
  > the maintenance of Emacs by someone like myself, can co-exist without
  > involving ethical compromise by either one of us, I'm happy for us to work
  > together.

I am very glad.  However, another message reminded me that the
maintainer's responsibility includes some other practical tasks that
relate to the GNU Project's philosophy, that I forgot about when
writing my previous message.  I had better correct that omission now.

They include (1) making sure we have copyright papers from substantial
contributors, (2) keeping track of authorship of contributions, and
(3) on rare occasions implementing or maintaining code to support
either the GPL requirements (as in the case of dynamic linking) or
informing people about the philosophy (such as the command C-h g)

I can't be absolutely sure I haven't omitted anything else.  If there
are any other such tasks, they would in any case be practical tasks,
like those above.

I am making everything clear and explicit, modulo the imperfections
of my memory.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: New maintainer

[John Wiegley]

>>>>> Richard Stallman <rms@gnu.org> writes:

> They include (1) making sure we have copyright papers from substantial
> contributors, (2) keeping track of authorship of contributions, and (3) on
> rare occasions implementing or maintaining code to support either the GPL
> requirements (as in the case of dynamic linking) or informing people about
> the philosophy (such as the command C-h g)

Understood, and not arguments from me here. Since Emacs is an GNU project, it
should remain consistent with the needs of GNU.

John

Re: New maintainer

[Jens K. Loewe]

Ah, finally an interesting discussion here.

> The whole point of GNU is the non-acceptance of software denying
> the users the fundamental software freedoms.

So GNU does not stand *for* something but *against* something? GNU's
whole point is not to be better than others but to point out that others
are worse? That reminds me of a kindergarten.

Furthermore, shouldn't it be the right of a free user to use a non-free
system at his own will? I don't use GNU for the sole reason that I get
my things done fast on other platforms, but I solve a lot of problems
with FLOSS software even on closed platforms. Am I a bad guy now?

I actually considered suggesting myself as a maintainer just to
contribute at least something to Emacs. I never wrote
"upstream" code for Emacs but I do that team development thing for
money. I guess as a Windows and BSD user I'm out of the game though - I
disagree with some of the points the GPL makes and I'll always prefer
the BSD infrastructure to GNU; but I really like working with
Emacs. However, it seems that the Emacs product is less important than
the Emacs "philosophy" here. No wonders that you can't find a
volunteer for ethical management on a technical mailing list.

Sigh.

JKL

--
I could contain traces of nuts.

Re: New maintainer

[Tassilo Horn]

jens.k.loewe@googlemail.com (Jens K. Loewe) writes:

>> The whole point of GNU is the non-acceptance of software denying the
>> users the fundamental software freedoms.
>
> So GNU does not stand *for* something but *against* something? GNU's
> whole point is not to be better than others but to point out that
> others are worse? That reminds me of a kindergarten.

The mission of GNU is to give users the ability to do all their
computing needs with software that respects their freedom.  Raising
awareness that software has also non-technical aspects is also a point
of that.

> Furthermore, shouldn't it be the right of a free user to use a
> non-free system at his own will?  I don't use GNU for the sole reason
> that I get my things done fast on other platforms, but I solve a lot
> of problems with FLOSS software even on closed platforms.  Am I a bad
> guy now?

Obviously not.  A user should have the ultimate freedom to use whatever
he prefers, and of course, we advocate for making users aware of freedom
being an important factor.  But from the point of view of GNU, when the
possibilities he can choose from don't include a free alternative,
that's an unacceptable situation where GNU must take action.  That could
mean providing a free alternative or advocating against that thing in
case there cannot be a free alternative (e.g., for DRM there cannot be a
free alternative).

> However, it seems that the Emacs product is less important than the
> Emacs "philosophy" here.

It's actually very simple: there won't be a technical feature which
relies on or works best with proprietary components because that would
encourage users to give up some of their freedom for technical merits.

Bye,
Tassilo

Re: New maintainer

[David Kastrup]

jens.k.loewe@googlemail.com (Jens K. Loewe) writes:

> Ah, finally an interesting discussion here.
>
>> The whole point of GNU is the non-acceptance of software denying
>> the users the fundamental software freedoms.
>
> So GNU does not stand *for* something but *against* something?

"Justice" and "fairness" and "freedom" are things that stand
fundamentally against letting things run their natural course,
downwards.

> GNU's whole point is not to be better than others but to point out
> that others are worse?

Nonsense.  GNU's point is to stand for software that is and remains free
to share, modify, run, and study.  It does not do so in a vacuum: it
would not be necessary to take a stand if there was an overall trend to
respect user and developer freedom.  Taking a stand does not happen in a
vacuum.

> That reminds me of a kindergarten.
>
> Furthermore, shouldn't it be the right of a free user to use a
> non-free system at his own will?

It is the definition of a non-free system that you cannot use it at your
own will in many respects.  At any rate, freedom does not mean a
different prescribed path but a choice.  How you use the choice is yours
but it is important that you have the choice in the first place.

The difference between a home and a prison is not how often you go
outside, but whether you can.

The point of the GNU project is to support free software.

If you are to manage a vegetarian fair and your idea of improvement
focuses on the sorely missing hot dog stands and you think a show
tannery a great addition, you are out of your depth.  That's different
from hiring bouncers who keep everybody out wearing leather shows or
stuff.

But a project manager is not managing the visitors, he is managing the
booths and stalls.  And regardless of whether he or she likes a nice
juicy steak at home, a steak hut does not belong on the fair.  And if
his main motivation for organizing the fair was getting the best steak
hut far and wide, he is a mismatch for the fair, even if 90% of all
visitors happen to eat meat at home.

GNU has a message, and as a core project manager one cannot afford to
ignore it.

A church custodian does not need to be devout, but it won't be
acceptable to celebrate orgies in the church either.  He needs to be
aware what the subject of his job and its sensibilities are and deal
respectably with it.

> I don't use GNU for the sole reason that I get my things done fast on
> other platforms, but I solve a lot of problems with FLOSS software
> even on closed platforms. Am I a bad guy now?

Sounds like a utilitarian to me.  I'm not sure why so many people insist
they deserve special praise for going the path of least resistance and
why they consider people offensive who try doing better than that.

I get this sort of defensive-aggressiveness a lot.  I'm not interested
in the life stories and explanations of people who need to convince
themself of something by talking down my life choices.

> I actually considered suggesting myself as a maintainer just to
> contribute at least something to Emacs. I never wrote "upstream" code
> for Emacs but I do that team development thing for money. I guess as a
> Windows and BSD user I'm out of the game though - I disagree with some
> of the points the GPL makes and I'll always prefer the BSD
> infrastructure to GNU; but I really like working with Emacs. However,
> it seems that the Emacs product is less important than the Emacs
> "philosophy" here. No wonders that you can't find a volunteer for
> ethical management on a technical mailing list.

Nobody is looking for an "ethical manager" here.  The FSF has one
already.  But even a technical manager needs to be aware of the
principles of the GNU project and deal with the tasks responsibly that
those imply for the technical management.  Stuff like making sure that
the respective copyright assignments for contributions are in place,
even if neither the manager nor the contributor believes in them, making
sure that the policies with regard to software only available for
specific platforms are heeded, and even making sure that stuff like
plugin interfaces is done in a manner consistent with the discussions
with Richard and other key persons.

That can mean that a technical manager not invested into GNU's
philosophy will likely have to deal with a few things he considers
technically awkward.  That's hopefully a minuscule part of the job, but
when it does occur it still needs to be done in a responsible and
responsive manner.

-- 
David Kastrup

Re: New maintainer

[Jens K. Loewe]

David Kastrup schrob am 04. Okt. 2015 um 17:49 Uhr dies:

> "Justice" and "fairness" and "freedom" are things that stand
> fundamentally against letting things run their natural course,
> downwards.

So you say it's wrong to let the user work with the best tool for his
job if it's not free?

> It is the definition of a non-free system that you cannot use it at your
> own will in many respects.

This implies that every user has the will to know how his preferred tool
does the job he wants to use it for. This is wrong. Let's take the
famous example "write a letter": Why do you think your Grandma has to
know the internals of Microsoft Word when Microsoft Word is the tool
that makes her finish any letter faster than LibO or OOo?

> The point of the GNU project is to support free software.

That sounds different and better from "the point is to fight non-free
software", do you agree?

> If you are to manage a vegetarian fair and your idea of improvement
> focuses on the sorely missing hot dog stands and you think a show
> tannery a great addition, you are out of your depth.

I use GNU tools (well, at least Emacs) on non-free systems and I
strongly disagree with your interpretation. I don't say "GNU should make
more Windows software" and I even agree with the ethical disapproval of
Apple's products, *but* I say that a focus on so-called "free systems"
is implying a restriction. Not being actively interested in maintaining
compatibility with Windows means a lock-in for non-Windows systems.

Being able to use GNU tools on non-GNU systems often leads to the
thought that switching the OS would not be much effort.

> And if his main motivation for organizing the fair was getting the
> best steak hut far and wide, he is a mismatch for the fair, even if
> 90% of all visitors happen to eat meat at home.

The best free tool is a tool that does not require you to change your
operating system, do you agree?

> A church custodian does not need to be devout, but it won't be
> acceptable to celebrate orgies in the church either.

No one implied to do so. None of the aspirants for the GNU Emacs
maintainership suggested to start a Windows party on this mailing list,
did we?

There's a huge difference between maintaining a software and living an
idea. Can a software only be good when its maintainer has /the right
mind/?

> Nobody is looking for an "ethical manager" here.  The FSF has one
> already.  But even a technical manager needs to be aware of the
> principles of the GNU project and deal with the tasks responsibly that
> those imply for the technical management.

I know the difference between agreement and awareness. I'm pretty sure
that even I could follow the rules of the GPL and the GNU manifesto
without necessarily agreeing to all of them. Managing a task is
different from doing that task.

I can enforce a license which I don't comply with for my own stuff when
it is a part of my job (which it would be in this case). I guess that
applies to everyone here.

> That can mean that a technical manager not invested into GNU's
> philosophy will likely have to deal with a few things he considers
> technically awkward.

Which is OK as long as it does not have a major influence in what he
does IMO.

JKL


-- 
I could contain traces of nuts.

Re: New maintainer

[John Wiegley]

>>>>> Jens K Loewe <jens.k.loewe@googlemail.com> writes:

> So you say it's wrong to let the user work with the best tool for his job if
> it's not free?

Hi Jens,

I'm not sure emacs-devel is still the place to continue this discussion,
especially since we haven't found a new maintainer yet, and that was the
objective for this thread.

I believe the FSF has other forums where you could raise this concern, if
someone from that group could point them out.

John

Re: New maintainer

[David Kastrup]

jens.k.loewe@googlemail.com (Jens K. Loewe) writes:

> David Kastrup schrob am 04. Okt. 2015 um 17:49 Uhr dies:
>
>> The point of the GNU project is to support free software.
>
> That sounds different and better from "the point is to fight non-free
> software", do you agree?

Since there enough users who do not care one bit, you don't get one
without the other.  The playfield is tilted.

The whole point of the GPL is to reject non-free software rather than
not care any which way like the BSD licenses do.

>> If you are to manage a vegetarian fair and your idea of improvement
>> focuses on the sorely missing hot dog stands and you think a show
>> tannery a great addition, you are out of your depth.
>
> I use GNU tools (well, at least Emacs) on non-free systems and I
> strongly disagree with your interpretation. I don't say "GNU should
> make more Windows software" and I even agree with the ethical
> disapproval of Apple's products, *but* I say that a focus on so-called
> "free systems" is implying a restriction.

Oh definitely.  And the GPL is restricting software to be used only as a
building piece for free software.  That's its sole point.

> Not being actively interested in maintaining compatibility with
> Windows means a lock-in for non-Windows systems.
>
> Being able to use GNU tools on non-GNU systems often leads to the
> thought that switching the OS would not be much effort.

Look, Windows 10 contains keyloggers that record any key combinations of
you and send them to Redmond to "make your computing experience more
enjoyable".  They reserve the right to sell every information they gain
about you for any purpose.  The operating system is malware to a degree
where the most money-grabbing software company in the world does not
want you to pay a dime for it (likely because then you'd have some
minimal rights) and will force the upgrade on users of older Windows
systems.

People for whom such a system is a serious consideration do not care
about freedom one bit.  Bending over backwards for them so that they can
keep getting screwed over is not going to make them change their mind.
We don't really have more convincing arguments to change from Windows or
MacOSX to offer than the Windows EULA and privacy agreements and MacOSX
licenses.  If you can read through all that and wholeheartedly state
"I agree", then we don't have anything to offer, really.

For every new Windows system, the EULA has become more ridiculous.
MacOS was comparatively benign in that regard for a long time since the
hardware (and to some degree the not-easily-replaceable firmware ROMs)
served as a sort of dongle, not necessitating additional thumbscrews
over what copyright already provided.

But right now by far the most important consideration has to be to make
GNU software work well in connection with free systems since the unfree
systems are so far off the chart that catering for them is not providing
a free work environment in sufficiently tangible respects.

>> And if his main motivation for organizing the fair was getting the
>> best steak hut far and wide, he is a mismatch for the fair, even if
>> 90% of all visitors happen to eat meat at home.
>
> The best free tool is a tool that does not require you to change your
> operating system, do you agree?

The best vegetarian dinner is a sideplate to a juicy steak, do you
agree?

>> A church custodian does not need to be devout, but it won't be
>> acceptable to celebrate orgies in the church either.
>
> No one implied to do so. None of the aspirants for the GNU Emacs
> maintainership suggested to start a Windows party on this mailing
> list, did we?

The issue here was actually MacOSX, resulting in a reminder of the rule
that no functionality is to be introduced for non-free operating systems
that is not available for GNU/Linux.

> There's a huge difference between maintaining a software and living an
> idea. Can a software only be good when its maintainer has /the right
> mind/?

You seem to be fond of flogging that strawman.  I repeat: the maintainer
does not need to have certain personal beliefs but he must be able to
understand and follow the rules governing and underlying the project.

>> That can mean that a technical manager not invested into GNU's
>> philosophy will likely have to deal with a few things he considers
>> technically awkward.
>
> Which is OK as long as it does not have a major influence in what he
> does IMO.

In some respects, it will.  That makes it harder to find a person for
what amounts to an unpaid position since it means that the only person
doing such a job will have strong reasons of his own.  And when those
reasons are partly in conflict with the FSF's goals, that takes an
impact on the satisfaction one can derive from such a job as one's
metric for doing it well might not be in complete concord with the FSF's
metric.

-- 
David Kastrup

Re: New maintainer

[Jens K. Loewe]

David Kastrup schrob am 04. Okt. 2015 um 23:34 Uhr dies:

> Since there enough users who do not care one bit, you don't get one
> without the other.  The playfield is tilted.

I guess the FSF is in a position where they can shuffle the playfield if
they'd want to.

> Oh definitely.  And the GPL is restricting software to be used only as
> a building piece for free software.  That's its sole point.

So the actual point of this was that a GNU Emacs maintainer has to
enforce software restrictions to users? That sounds wrong.

> Look, Windows 10 contains keyloggers that record any key combinations of
> you and send them to Redmond to "make your computing experience more
> enjoyable".

You might have missed it, but Windows 10 *actually asks you* if you want
to enable this feature during the first set-up steps, so it's basically
opt-in. People who propagate the right to choose should appreciate this
IMO.

> People for whom such a system is a serious consideration do not care
> about freedom one bit.

This is not valid. I like my freedom, I use quite a couple of different
operating systems, both free and non-free. The free ones are mostly used
for technical reasons indeed, but I still do most of my work on
Windows. Not because Windows was free or something, but because I can
get my things done with it. Switching to another main OS would force me
to develop an entirely new workflow - which would decrease my
productivity.

I still don't think I don't care about freedom. I might repeat myself: I
am an active contributor to and user of some FLOSS projects (including
some you might know), I just happen to have the /perfect/ workflow on
Windows. Don't condemn me for wishing to use a tool (my computer) as a
tool and not as a church.

> If you can read through all that and wholeheartedly state "I agree",
> then we don't have anything to offer, really.

How many people have read Canonical's terms of service in the first
place?

> The best vegetarian dinner is a sideplate to a juicy steak, do you
> agree?

I like steak, so no complaints on this point... ;-)

> The issue here was actually MacOSX, resulting in a reminder of the rule
> that no functionality is to be introduced for non-free operating systems
> that is not available for GNU/Linux.

Which is a pretty OK rule, I just wanted you to consider that having a
"broken by design" Windows or OSX version of a GNU tool will rather make
people drop the tool than their operating system.

>> Which is OK as long as it does not have a major influence in what he
>> does IMO.
>
> In some respects, it will.

Which would be those respects?

> That makes it harder to find a person for
> what amounts to an unpaid position since it means that the only person
> doing such a job will have strong reasons of his own.

The reason I suggested myself was that I wanted to contribute something
to GNU Emacs because I love it and its community and I wish that I can
give you something back. I guess that reason is strong enough and not in
conflict with anything?

Regards.

JKL


-- 
I could contain traces of nuts.

Re: New maintainer

[Dmitry Gutov]

On 10/05/2015 01:28 AM, Jens K. Loewe wrote:

> Which is a pretty OK rule, I just wanted you to consider that having a
> "broken by design" Windows or OSX version of a GNU tool will rather make
> people drop the tool than their operating system.

Why don't we stop this thread of discussion right here?

Emacs is highly unlikely to become "broken by design" on Windows or OS X 
while there are volunteers willing to contribute their time to that purpose.

The only "breakage" that's likely to occur is Emacs can have features 
not working there, while being functional on GNU platforms. That will 
also be predicated on whether a feature in question needs special 
support for the OS in question, and whether there are volunteers 
interested in contributing that support.

Re: New maintainer

[David Kastrup]

jens.k.loewe@googlemail.com (Jens K. Loewe) writes:

> David Kastrup schrob am 04. Okt. 2015 um 23:34 Uhr dies:
>
>> Since there enough users who do not care one bit, you don't get one
>> without the other.  The playfield is tilted.
>
> I guess the FSF is in a position where they can shuffle the playfield
> if they'd want to.

Nonsense.  They can just level their corner.

>> Oh definitely.  And the GPL is restricting software to be used only
>> as a building piece for free software.  That's its sole point.
>
> So the actual point of this was that a GNU Emacs maintainer has to
> enforce software restrictions to users? That sounds wrong.

Shrug.  I don't see the point in providing a target for you letting you
twist words around.  You obviously have an agenda from which you don't
want to get deterred.  The GPL works by posing restrictions to the
manner in which software is subverted, and a GNU project maintainer is
expected to keep projects in a state where the GPL is effective in
ensuring software freedom.

This won't get better or worse by you trying to put absurd spins on it.

>> Look, Windows 10 contains keyloggers that record any key combinations
>> of you and send them to Redmond to "make your computing experience
>> more enjoyable".
>
> You might have missed it, but Windows 10 *actually asks you* if you
> want to enable this feature during the first set-up steps, so it's
> basically opt-in. People who propagate the right to choose should
> appreciate this IMO.

You might have missed it, but Windows 10 goes ahead nevertheless.  So
far testers have not been able to find any settings that would not send
a continuous string of data related to keypresses to Microsoft servers.

>> People for whom such a system is a serious consideration do not care
>> about freedom one bit.
>
> I still don't think I don't care about freedom. I might repeat myself:
> I am an active contributor to and user of some FLOSS projects
> (including some you might know), I just happen to have the /perfect/
> workflow on Windows.

Perfect means that there is nothing wrong with it for you, so "do not
care about freedom one bit" seems to be a pretty good description.

> Don't condemn me for wishing to use a tool (my computer) as a tool and
> not as a church.

I don't condemn you.  I state that you don't care for freedom one bit.
And you state that perfection for you does not involve freedom.  And
that people for which this is different are using their computer as a
church.  Which presumably is something bad.

>> If you can read through all that and wholeheartedly state "I agree",
>> then we don't have anything to offer, really.
>
> How many people have read Canonical's terms of service in the first
> place?

Uh, there's not all that much in there if you don't actually enter
service contracts.  Their contributor agreements are more on the
debatable side, but they don't concern end user freedom all that much.

>> The best vegetarian dinner is a sideplate to a juicy steak, do you
>> agree?
>
> I like steak, so no complaints on this point... ;-)

But you do understand that you have to leave that preference at home
when you agree to organize a vegetarian fair or you'll be the wrong
person for the job?

-- 
David Kastrup

Re: New maintainer

[Jens K. Loewe]

David Kastrup schrob am 05. Okt. 2015 um 01:20 Uhr dies:

> Nonsense.  They can just level their corner.

They have a loyal fanbase though. (Don't take this word too seriously
please.)

> You obviously have an agenda from which you don't want to get
> deterred.

My so-called "agenda" is to try to understand what I /might/ have got
wrong in order to be able to keep up with the discussions. I just don't
consider something -- not even "this or that is freedom" -- to be right
just because someone said so. Sorry.

> a GNU project maintainer is expected to keep projects in a state where
> the GPL is effective in ensuring software freedom.

Which, again, is OK and perfectly understandable for me.

> You might have missed it, but Windows 10 goes ahead nevertheless.  So
> far testers have not been able to find any settings that would not
> send a continuous string of data related to keypresses to Microsoft
> servers.

Yes, I have missed that yet. Thank you.

> Perfect means that there is nothing wrong with it for you, so "do not
> care about freedom one bit" seems to be a pretty good description.

This is the difference between using a computer as a tool and using a
computer as a church again. I know that Windows does not let me have all
the freedom I could want to (this is one of the reasons why I own other
machines with other operating systems too), it's just that I, sometimes,
don't need to have (e.g.) a way to patch my Windows kernel. Sometimes I
just want to use it as it was meant to be used.

I'd happily drop Windows when someone invents a free operating system
which provides adequate alternatives to the proprietary software I use.

> I don't condemn you.  I state that you don't care for freedom one bit.
> And you state that perfection for you does not involve freedom.  And
> that people for which this is different are using their computer as a
> church.  Which presumably is something bad.

Well, yes. A computer is a tool to me, like a hammer is a tool. I use a
hammer to drive a nail into the wall, I use a computer to communicate
with people (in a couple of ways, admittedly). When I need something to
drive a nail into a wall, it does not matter much to me if I can replace
its head with a different head as long as it gets its task done.

It's still wrong that I don't care for freedom, I'm just skeptical about
enforcing freedom as /enforcing/ is quite the opposite of
/freeing/. But, again, that does not mean that I come with the "wrong
mind". My personal choice of software is a result of my freedom to
choose, and you won't ever see my advocating a closed system unless for
a very good reason.

> But you do understand that you have to leave that preference at home
> when you agree to organize a vegetarian fair or you'll be the wrong
> person for the job?

Yes, of course. I never said I wouldn't. However, as of now, I'm here as
a non-representative user, so everything I write is not a part of a
job. If a job involved advocating the GPL, I'd follow the rules.

JKL


-- 
I could contain traces of nuts.

Re: New maintainer

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Mon, 05 Oct 2015 01:20:16 +0200
> Cc: emacs-devel@gnu.org
> 
> >> Look, Windows 10 contains keyloggers that record any key combinations
> >> of you and send them to Redmond to "make your computing experience
> >> more enjoyable".
> >
> > You might have missed it, but Windows 10 *actually asks you* if you
> > want to enable this feature during the first set-up steps, so it's
> > basically opt-in. People who propagate the right to choose should
> > appreciate this IMO.
> 
> You might have missed it, but Windows 10 goes ahead nevertheless.  So
> far testers have not been able to find any settings that would not send
> a continuous string of data related to keypresses to Microsoft servers.

Google did, among its first few hits:

  http://www.express.co.uk/life-style/science-technology/603524/Windows-10-Microsoft-Key-Logger-Record-Privacy
  http://arstechnica.com/information-technology/2015/08/windows-10-doesnt-offer-much-privacy-by-default-heres-how-to-fix-it/

Re: New maintainer

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Mon, 05 Oct 2015 01:20:16 +0200
>> Cc: emacs-devel@gnu.org
>> 
>> >> Look, Windows 10 contains keyloggers that record any key combinations
>> >> of you and send them to Redmond to "make your computing experience
>> >> more enjoyable".
>> >
>> > You might have missed it, but Windows 10 *actually asks you* if you
>> > want to enable this feature during the first set-up steps, so it's
>> > basically opt-in. People who propagate the right to choose should
>> > appreciate this IMO.
>> 
>> You might have missed it, but Windows 10 goes ahead nevertheless.  So
>> far testers have not been able to find any settings that would not send
>> a continuous string of data related to keypresses to Microsoft servers.
>
> Google did, among its first few hits:
>
>   http://www.express.co.uk/life-style/science-technology/603524/Windows-10-Microsoft-Key-Logger-Record-Privacy
>   http://arstechnica.com/information-technology/2015/08/windows-10-doesnt-offer-much-privacy-by-default-heres-how-to-fix-it/

Ah, but turning those settings off does not really suffice.

<URL:http://arstechnica.com/information-technology/2015/08/even-when-told-not-to-windows-10-just-cant-stop-talking-to-microsoft/>

-- 
David Kastrup

Re: New maintainer

[Artur Malabarba]

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

There's a lot of non-maintainer-related discussion here. Everyone please
(at least) branch these discussions off into their own subjects and stop
drowning the  "New maintainer" thread.

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

Re: New maintainer

[Michael Westbom]

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

I second the motion to move unrelated topics of discussion to a new thread or different forum—fascinating as they may be (I hope, wherever the discussion lands next, that I may continue to follow).



-- 
Michael Westbom

On October 5, 2015 at 2:56:46 AM, Artur Malabarba (bruce.connor.am@gmail.com) wrote:

There's a lot of non-maintainer-related discussion here. Everyone please (at least) branch these discussions off into their own subjects and stop drowning the  "New maintainer" thread.


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

Re: New maintainer

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: jens.k.loewe@googlemail.com,  emacs-devel@gnu.org
> Date: Mon, 05 Oct 2015 08:15:41 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: David Kastrup <dak@gnu.org>
> >> Date: Mon, 05 Oct 2015 01:20:16 +0200
> >> Cc: emacs-devel@gnu.org
> >> 
> >> You might have missed it, but Windows 10 goes ahead nevertheless.  So
> >> far testers have not been able to find any settings that would not send
> >> a continuous string of data related to keypresses to Microsoft servers.
> >
> > Google did, among its first few hits:
> >
> >   http://www.express.co.uk/life-style/science-technology/603524/Windows-10-Microsoft-Key-Logger-Record-Privacy
> >   http://arstechnica.com/information-technology/2015/08/windows-10-doesnt-offer-much-privacy-by-default-heres-how-to-fix-it/
> 
> Ah, but turning those settings off does not really suffice.
> 
> <URL:http://arstechnica.com/information-technology/2015/08/even-when-told-not-to-windows-10-just-cant-stop-talking-to-microsoft/>

Which includes further advice on how to turn the other stuff off.

Look, this particular point of yours is simply invalid: for any
problem encountered on Windows, there are always solutions and/or
workarounds that work.  It sometimes takes time to discover them
(Windows 10 was released only 2.5 months ago), but eventually they do
surface.  The enormously large number of people using Windows and the
basic user desire to solve problems they bump into, coupled with the
Internet and the efficiency of the search engines, makes any such
malware-like features easily bypassed for those who don't want them.

The basis for the Free Software movement and the GPL, as I understand
it, was, and still is, that denying free access to the software
sources prevents the free flow and exchange of ideas, which is
immoral, unethical, and detrimental to progress, and whose only
justification is greed and the desire to increase profits.  The
supposedly easier way of fixing bugs and adding features by the user
herself is IMO a beneficial side-effect, and is today limited to
adding features (as workarounds for bugs will usually be found by
googling).  The free flow of ideas argument is still very much valid,
although it, too, is not black-and-white anymore, because there's
enormous amount of information out there, both in books and in
articles, that describes the inner workings of Windows (don't know
about MacOS, OS X etc.) to astonishing depth and detail.

Bottom line, I submit that representing the split as black-and-white
chasm-like one is nowadays a misrepresentation.  Things are more like
shades of gray, not in the least due to the fact that the modern
societies are much more open than they were in 1980s.  Which goes a
long way towards explaining why people don't easily see the core of
the GPL's rationale and quite a few are sincerely confused about the
Free Software movement's main principles and ideas.  It also makes our
job explaining those ideas quite a bit harder.  But trying to make it
easier by representing the issues as black-and-white is not TRT, IME,
and it will always fail given an intelligent enough opponent who knows
her ground.  You (not you personally, David) can even be accused in
trying to con your audience by false statements, which then might have
far-reaching effect on our argumentation in general.

Re: New maintainer

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Cc: jens.k.loewe@googlemail.com,  emacs-devel@gnu.org
>> Date: Mon, 05 Oct 2015 08:15:41 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: David Kastrup <dak@gnu.org>
>> >> Date: Mon, 05 Oct 2015 01:20:16 +0200
>> >> Cc: emacs-devel@gnu.org
>> >> 
>> >> You might have missed it, but Windows 10 goes ahead nevertheless.  So
>> >> far testers have not been able to find any settings that would not send
>> >> a continuous string of data related to keypresses to Microsoft servers.
>> >
>> > Google did, among its first few hits:
>> >
>> >   http://www.express.co.uk/life-style/science-technology/603524/Windows-10-Microsoft-Key-Logger-Record-Privacy
>> >   http://arstechnica.com/information-technology/2015/08/windows-10-doesnt-offer-much-privacy-by-default-heres-how-to-fix-it/
>> 
>> Ah, but turning those settings off does not really suffice.
>> 
>> <URL:http://arstechnica.com/information-technology/2015/08/even-when-told-not-to-windows-10-just-cant-stop-talking-to-microsoft/>
>
> Which includes further advice on how to turn the other stuff off.

Have we been reading the same article?  "We've asked Microsoft if there
is any way to disable this additional communication or information about
what its purpose is." ... "if Web searching and Cortana are disabled, we
suspect that the inference that most people would make is that searching
the Start menu wouldn't hit the Internet at all. But it does. The
traffic could be innocuous, but the inclusion of a machine ID gives it a
suspicious appearance."

> Look, this particular point of yours is simply invalid: for any
> problem encountered on Windows, there are always solutions and/or
> workarounds that work.  It sometimes takes time to discover them
> (Windows 10 was released only 2.5 months ago), but eventually they do
> surface.  The enormously large number of people using Windows and the
> basic user desire to solve problems they bump into, coupled with the
> Internet and the efficiency of the search engines, makes any such
> malware-like features easily bypassed for those who don't want them.

Do you or don't you agree that there is a point for an operating system
respecting the user's choices, privacy and control?  Because we are
talking here about the need of a prospective Emacs manager to heed the
policies designed to ensuring that such a system remains available in
future and cannot be watered down easily.  Even while the availability
of such systems depressingly appears to have very little impact on
users' choices, it's the GNU mission to make sure that for those few who
actually care, the choice remains.

With Emacs being a core component of GNU, the maintainer needs to accept
that he is not independently responsible for Emacs but also for GNU.

> But trying to make it easier by representing the issues as
> black-and-white is not TRT, IME, and it will always fail given an
> intelligent enough opponent who knows her ground.  You (not you
> personally, David) can even be accused in trying to con your audience
> by false statements, which then might have far-reaching effect on our
> argumentation in general.

I wish.  Unfortunately, the world is moving away from shades of grey and
rather thoroughly into contrasts increasingly indistinguishable from
black-and-white.  The idea that systems like GNU were needed to keep the
big players in check by offering a free alternative has mostly failed.
It does not help that MacOSX is these days built based on a free but
non-copylefted platform.  And even the Android universe built around a
GPLed kernel is at best a thoroughly mixed blessing and its effective
level of freedom is much more determined by the marketing department of
Google than by the workers on the free software base they are employing.

Oh, and Google, in the course of changing its company name has also
chosen to drop its motto "do no evil" in favor of the fuzzier and less
absolute "do the right thing".

That is the general situation where the FSF with the GNU project tries
to carve out and maintain a harbor of freedom and Emacs is one of the
few core products and resources it has to work with, and so it is
important that the maintainer will respect the aspects of his work
concerned with that.  It's not like they push themselves in the
foreground that often.

In my opinion, _particularly_ if you care about recommending and working
with Windows and MacOSX, you should be concerned about a solid
counterweight that those systems may be held against in their current
downward spiral.  That decline can only be slowed if people start caring
about their rights and privacy, and a viable alternative is the most
important asset for that.

-- 
David Kastrup

Re: New maintainer

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: jens.k.loewe@googlemail.com,  emacs-devel@gnu.org
> Date: Mon, 05 Oct 2015 09:36:30 +0200
> 
> >> Ah, but turning those settings off does not really suffice.
> >> 
> >> <URL:http://arstechnica.com/information-technology/2015/08/even-when-told-not-to-windows-10-just-cant-stop-talking-to-microsoft/>
> >
> > Which includes further advice on how to turn the other stuff off.
> 
> Have we been reading the same article?

Yes.  It's a long article, not just the 2 sentences you've cited.

> "We've asked Microsoft if there is any way to disable this
> additional communication or information about what its purpose is."
> ... "if Web searching and Cortana are disabled, we suspect that the
> inference that most people would make is that searching the Start
> menu wouldn't hit the Internet at all. But it does. The traffic
> could be innocuous, but the inclusion of a machine ID gives it a
> suspicious appearance."

"We suspect", "could be innocuous", "suspicious appearance", etc. here
mean that the authors don't really know themselves whether there is a
problem.

In any case, wait a bit, and more information will surely surface
about disabling that, if there is indeed a problem.

> Do you or don't you agree that there is a point for an operating system
> respecting the user's choices, privacy and control?

I do, but the GPL in my reading is not about privacy and choices.
There could be a GPL'ed program that doesn't care about privacy and
gives the users little control on its operation.  (It would be a bad
program, IMO.)

Protecting privacy and giving users more control are all good
principles for building user-friendly software, and I very much hope
Emacs and the rest of the GNU project will do that.  But they have
nothing to do with software freedom of the GPL itself, IMO.  Lumping
them together just muddies the waters.

> Because we are
> talking here about the need of a prospective Emacs manager to heed the
> policies designed to ensuring that such a system remains available in
> future and cannot be watered down easily.  Even while the availability
> of such systems depressingly appears to have very little impact on
> users' choices, it's the GNU mission to make sure that for those few who
> actually care, the choice remains.
> 
> With Emacs being a core component of GNU, the maintainer needs to accept
> that he is not independently responsible for Emacs but also for GNU.

All true and agreed.  All I'm saying is that the specific point you
were trying to make regarding malware-type misfeatures of Windows 10
is not relevant to this.

> > But trying to make it easier by representing the issues as
> > black-and-white is not TRT, IME, and it will always fail given an
> > intelligent enough opponent who knows her ground.  You (not you
> > personally, David) can even be accused in trying to con your audience
> > by false statements, which then might have far-reaching effect on our
> > argumentation in general.
> 
> I wish.  Unfortunately, the world is moving away from shades of grey and
> rather thoroughly into contrasts increasingly indistinguishable from
> black-and-white.

I strongly disagree, but I don't want to argue about that, certainly
not here.

> if you care about recommending and working with Windows and MacOSX

I don't.

Re: New maintainer

[Michael Westbom]

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

I’m new to this mailing list and happen to find it in a morass of maintainership discussion quite by coincidence; weigh my comments as you will.

I’d like to offer a solid +1 to Mr. Wiegley’s maintainership of Emacs.

After having witnessed his conduct on this thread, as well as being familiar with his name through seeing it on the by-line of many an excellent work over the last couple years (in other words, about as long as I’ve been using Emacs), I believe his depth of knowledge, clarity of vision, and capacity for technical writing are well suited to the task.



-- 
Michael Westbom

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

Re: New maintainer

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I do, but the GPL in my reading is not about privacy and choices.
  > There could be a GPL'ed program that doesn't care about privacy and
  > gives the users little control on its operation.

Free software does not guarantee the absence of malfeatures,
but free software puts the users in control of the program
which enables the user community to fix any malfeatures.
This in turn reduces the temptation to introduce malfeatures.

See http://gnu.org/philosophy/free-software-even-more-important.html
and fsf.org/tedx.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: New maintainer

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Ah, but turning those settings off does not really suffice.

  > <URL:http://arstechnica.com/information-technology/2015/08/even-when-told-not-to-windows-10-just-cant-stop-talking-to-microsoft/>

For more information about known malware functionalities
in many proprietary programs see http://gnu.org/proprietary/.

If you find an error in that information, or if you know about other
cases to add, please report it to webmasters@gnu.org.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: New maintainer

[Ricardo Wurmus]

Jens K. Loewe <jens.k.loewe@googlemail.com> writes:

>> The issue here was actually MacOSX, resulting in a reminder of the rule
>> that no functionality is to be introduced for non-free operating systems
>> that is not available for GNU/Linux.
>
> Which is a pretty OK rule, I just wanted you to consider that having a
> "broken by design" Windows or OSX version of a GNU tool will rather make
> people drop the tool than their operating system.

Just a data point: the frustrating experience of using Emacs on MacOS
has resulted in many complaints from a user about ... MacOS.  The user
is considering to move to a system that doesn’t arbitrarily restrict
freedom to the degree that it is done on MacOS.

(This is in the context of the world of bioinformatics, in which Windows
is hardly important, Macs are often used and complained about, and GNU
is the system that is actually supported by the local IT department.)

A tool is hardly “broken by design” when it works better on a particular
kind of system.  I rather think that it is a matter of degree: if the
tool is hardly usable at all, it probably would be dropped without a
second thought; if it can be used, even if not to the full extent as it
is useful on a free system, it can be enough to tip the scales in favour
of the free system.

~~ vegetarian Ricardo

Re: New maintainer

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

We don't need to debate about whether in principle GNU Emacs should
have support for MacOS.  There is a general GNU Project policy about
this.

The policy is non-GNU systems are secondary, and lower priority than
the GNU system, but we are glad to include support for them in GNU
packages if users contribute the necessary code -- provided that code
isn't a maintenance problem for us.

The maintenainers of any particular package are the ones who judge
whether that code is a maintenance problem, since they are the ones
it would be a problem for.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: New maintainer

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

This list is for developing GNU Emacs.  I state the GNU Project's
philosophy and rules here when that's pertinent to developing Emacs.

If you want to argue about the GNU Project's basic philosophy, we have
another list for that: gnu-misc-discuss@gnu.org.  Please take your
arguments there.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: New maintainer

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I think you've put it rightly and clearly.  We don't exclude people
who use proprietary software, or even people who develope proprietary
software, from using Emacs or even from developing Emacs.

I will mention one abstract subpoint where I disagree with what you
said.

  >   At any rate, freedom does not mean a
  > different prescribed path but a choice.

I think that defining freedom as "choice" is a mistaken approach.  All
else being equal, more freedom generally means you have more choices,
but defining freedom in terms of the number of choices leads to
paradoxes.

I define freedom as "having control of one's own life".
Freedom in one's computing means having control over how it is done,
which requires control over the software that does it.

Your church analogy was a good one, but let's make sure no one
misunderstands it as more than an analogy.  The Church of Emacs is
pure humor.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: New maintainer

[John Wiegley]

>>>>> Richard Stallman <rms@gnu.org> writes:

> I define freedom as "having control of one's own life". Freedom in one's
> computing means having control over how it is done, which requires control
> over the software that does it.

Even those of us who are fine using proprietary software have been bitten by
its lack of freedom. Why, I can't even run OS X on hardware of my own
choosing!

Let me be clear on the question of freedom: while I have disagreements with
you, I also don't consider any existing alternative to be ideal. I see pros
and cons in all of them. I choose BSD3 for my own software because it
represents the least commitment to any specific path.

So while I may disagree with the GPL as "The Way", I'm not opposed to helping
it succeed a little bit either. I think all these experiments need more time,
before we'll discover what truly helps our society progress in the ways we all
want it to.

> Your church analogy was a good one, but let's make sure no one
> misunderstands it as more than an analogy. The Church of Emacs is pure
> humor.

The church analogy, qua analogy, was pretty excellent. Point taken!

John

Re: New maintainer

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Furthermore, shouldn't it be the right of a free user to use a non-free
  > system at his own will?

We have never tried to people from running nonfree programs.
You seem to be attacking something that didn't come from us.

  > I guess as a Windows and BSD user I'm out of the game though - I
  > disagree with some of the points the GPL makes and I'll always prefer
  > the BSD infrastructure to GNU; but I really like working with
  > Emacs.

We are happy to accept contributions from BSD users -- I am sure you
have seen this -- and BSD is sufficiently similar to GNU that it
should not be an impediment in practice.

It is simply a matter of whether you wish to contribute.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: New maintainer

[David Reitter]

John,

> If the experience is great on GNU systems, but awful on OS X,
> I'll see this as meaning that changes needing to be made. Conversely, I won't
> notice degradation on GNU systems owing to cross-platform changes, and would
> require those using such systems to inform me.

Do you consider downstream projects a legitimate way of providing that experience on the basis of GPL principles without diluting the overall mission of the FSF and the GNU project?

By providing support and stability, the upstream project (Emacs) can foster an ecosystem that is ultimately a good advertisement to free software.  Downstream projects can reach a wider audience than the GNU-only system can, and they can incorporate libraries and functionalities that the upstream project is unwilling to adopt for philosophical reasons.  With the right relationship to these projects, some improvements can also be ported back and thus benefit everybody.

Re: New maintainer

[John Wiegley]

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

> Do you consider downstream projects a legitimate way of providing that
> experience on the basis of GPL principles without diluting the overall
> mission of the FSF and the GNU project?

Can you give an example?  I don't fully understand your question.

> By providing support and stability, the upstream project (Emacs) can foster
> an ecosystem that is ultimately a good advertisement to free software.
> Downstream projects can reach a wider audience than the GNU-only system can,
> and they can incorporate libraries and functionalities that the upstream
> project is unwilling to adopt for philosophical reasons. With the right
> relationship to these projects, some improvements can also be ported back
> and thus benefit everybody.

Sounds nice in principle, but an example would help me to be clear on what
that might look like in practice.

John

Re: New maintainer

[David Reitter]

On Oct 5, 2015, at 6:21 PM, John Wiegley <johnw@newartisans.com> wrote:
> 
>>>>>> David Reitter <david.reitter@gmail.com> writes:
> 
>> Do you consider downstream projects a legitimate way of providing that
>> experience on the basis of GPL principles without diluting the overall
>> mission of the FSF and the GNU project?
> 
> Can you give an example?  I don't fully understand your question.

I’m sorry, I thought that was obvious.

Since 2005, the Aquamacs project has been publishing its own Emacs distribution for the Mac, based on a recent stable or development-stage version of Emacs 22, 23, 24, and soon 25.    The version we distribute is patched at Lisp and C levels, and it comes packaged with a great deal of useful packages, including ESS and AUCTeX.  Last time I checked, we had about 12-14,000 regular users (not just installs).

It’s a downstream project implementing features that do not conform to all of GNU’s and the FSF’s policies, and addressing a non-free (but quite open) platform.  I think it still promotes freedom among those who choose this platform.

D

Re: New maintainer

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It’s a downstream project implementing features that do not
  > conform to all of GNU’s and the FSF’s policies, and addressing a
  > non-free

I have nothing against downstream projects in general.  That might be
a good way to handle MacOS support, if maintaining it in Emacs itself
is inconvenient.  (I seem to recall that that is the case, but I am
not sure.)

You mention that it doesn't follow all the GNU and FSF policies.
That might be very bad, or might not matter much, depending on the details 
not stated.

        (but quite open) platform.

One more illustration that "open" is insufficient.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: New maintainer

[Dmitry Gutov]

On 10/01/2015 11:46 PM, John Wiegley wrote:

> However: are you looking for someone to act as an arm of the FSF, or do you
> want the best possible Emacs?

I imagine you have to have a certain amount of respect for FSF policies.

Being a mouthpiece for RMS is not required, but liking GPL would help. 
We have enough drama here as it is.

Re: New maintainer

[Mathieu Lirzin]

John Wiegley <johnw@newartisans.com> writes:

> However: are you looking for someone to act as an arm of the FSF, or do you
> want the best possible Emacs?

As already answered by someone else, things are not incompatible.
Moreover it is precisely the purpose of the work done through the GNU
project, which is promoting freedom by technical contributions.

I just think you can make the best possible Emacs without being a
maintainer of it. ;)

--
Mathieu Lirzin

Re: New maintainer

[David Kastrup]

John Wiegley <johnw@newartisans.com> writes:

>>>>>> Mathieu Lirzin <mthl@openmailbox.org> writes:
>
>> What about Ethical skills? I would argue that technical skills are not
>> sufficient especially for maintaining a major GNU package like Emacs. Using
>> MacOSX & iOS as main operating systems and Hangout/Skype for communications,
>> seems incompatible with the role to me.
>
> I also disagree with the spirit of the GPL, vocally in fact. If the
> requisite for maintaining Emacs is that one use (GNU/)Linux and
> espouse the philosophies of RMS, that is not me.
>
> However: are you looking for someone to act as an arm of the FSF, or
> do you want the best possible Emacs?

Well, the GPL is what makes sure that I actually have the right to get
the best possible Emacs once it is distributed anywhere.  A lot of "best
possible Emacsen" lie by the wayside, starting with Gosling Emacs and
arguably ending with XEmacs.

Now Stephen Turnbull, the current XEmacs maintainer for longer than any
of his Emacsen colleagues with the possible exception of RMS, is not
making a point of "disagreeing with the spirit of the GPL" at all even
though it's sort of foisted onto XEmacs.  It's more like they are
driving XEmacs under different work parameters than Emacs is driven,
with different conclusions from the same set of principles.

I don't think that "vocally disagreeing with the spirit of the GPL"
would provide a maintainership retaining whatever it was that has
enabled Emacs to claw back its way to the front time and again.  There
have been a number of heated discussions between RMS and various
maintainers, but they did not concern the "spirit of the GPL" as much as
they did the best choices to make in order to get the most from it.

I wouldn't go as far as calling this "ethical skills" but yes, it seems
like a cultural mismatch that would appear likely to cause considerable
friction in choosing consistent priorities for ongoing development.

-- 
David Kastrup

Re: New maintainer

[Stephen J. Turnbull]

First, I second John's self-nomination.  I suspect it's a no-op given
his "disagreement with the spirit of the GPL", but FWIW I think he
would be an excellent Emacs maintainer.

I've reordered David's post to suit my own purposes, but the
attributions are all correct.

 > >>>>>> Mathieu Lirzin <mthl@openmailbox.org> writes:

 > >> What about Ethical skills?

IMO, John's ethical skills are unquestionable.  However, his
observations of the world and certain fundamental postulates lead him
to different conclusions about what is and isn't ethically required.

 > >> I would argue that technical skills are not sufficient
 > >> especially for maintaining a major GNU package like Emacs. Using
 > >> MacOSX & iOS as main operating systems and Hangout/Skype for
 > >> communications, seems incompatible with the role to me.

I disagree, as John evidently does.  By the way, if I didn't know he
would have self-nominated if he could, I would nominate Eli Zaretskii
as maintainer.  Do you have a problem with him?

 > John Wiegley <johnw@newartisans.com> writes:

 > > I also disagree with the spirit of the GPL, vocally in fact. If the
 > > requisite for maintaining Emacs is that one use (GNU/)Linux and
 > > espouse the philosophies of RMS, that is not me.

I wouldn't require use of the GNU OS, but I'm sorry if I am to
understand that you can't at least defend gnu.org/philosophy in
public.  I think that disqualifies you:

 > > However: are you looking for someone to act as an arm of the FSF,
 > > or do you want the best possible Emacs?

I would assume Richard is looking for an arm of the FSF, as he has
done in the past.  AIUI, a great Emacs must be first, a tool for
advancing software freedom, and second, the best tool for its
applications that it can be.  I have other reasons for not
volunteering myself (lack of technical qualifications and time being
the most easily mentioned), but I would have no trouble with
enthusiastically defending the FSF position *in public* when *wearing
my GNU Emacs maintainer hat*.  That's probably not good enough for
Richard, but I can't imagine anything less being acceptable.

David Kastrup writes:

 > Well, the GPL is what makes sure that I actually have the right to
 > get the best possible Emacs once it is distributed anywhere.  A lot
 > of "best possible Emacsen" lie by the wayside, starting with
 > Gosling Emacs and arguably ending with XEmacs.
 > 
 > Now Stephen Turnbull, the current XEmacs maintainer for longer than any
 > of his Emacsen colleagues with the possible exception of RMS, is not
 > making a point of "disagreeing with the spirit of the GPL" at all

That's too strong.  What I cannot disagree with is use of GPL in a
project that chooses it understanding the ramifications, nor in that
project's downstream.  Richard is a visionary, but he also understands
the practical implications of GPL as well as anybody, and he considers
the principle well worth the problems (and in some cases things that
others consider problems he considers benefits).

As long as Emacs is firmly in the GPL camp, I have no problem
defending the GPL on Emacs lists.  I'd rather let RMS do it
(authoritative), or you or Stefan or Eli do it (more credible), but
occasionally I've stepped up when nobody else does (especially on
technical legal issues).  And I defend the GPL (without my fingers
crossed :-) on XEmacs lists, and not just because it was foisted on
us.  (I can't do the same for the FDL, but that's another matter.)

What I do elsewhere is quite another matter.

The religious principle that software freedom is an inalienable human
right that Jefferson somehow forgot to include in the Bill of Rights
is what I disagree with.  I'm Jeffersonian -- when it comes to freedom,
"The tree of liberty must be refreshed from time to time with the
blood of patriots and tyrants."  We need to all hang together lest
they hang us separately (well, that was Franklin).

 > even though it's sort of foisted onto XEmacs.  It's more like they
 > are driving XEmacs under different work parameters than Emacs is
 > driven, with different conclusions from the same set of principles.
 > 
 > I don't think that "vocally disagreeing with the spirit of the GPL"
 > would provide a maintainership retaining whatever it was that has
 > enabled Emacs to claw back its way to the front time and again.

I don't think that has much to do with the periodic resurgence of
Emacs.  Stefan and Yidong mostly left advocacy of any kind up to RMS.
Stefan himself openly disagreed with RMS over support for non-copyleft
software.  Emacs's GPL being a fact, I would hope John would keep his
mouth shut about his disagreement while wearing his GNU Emacs
maintainer hat (not limited to participation in Emacs lists).

 > I wouldn't go as far as calling this "ethical skills" but yes, it
 > seems like a cultural mismatch that would appear likely to cause
 > considerable friction in choosing consistent priorities for ongoing
 > development.

I don't see that as a problem, really.  Choice of license and choice
of development directions are quite orthogonal, especially since the
GPL allows you to suck in software from any GPL-compatible project.

The real question is whether a "cultural mismatch" that was openly
displayed would reduce enthusiasm for work on Emacs among developers.
I have to admit I believe it would, for the same reasons I believe it
has been an advantage for Emacs in attracting and keeping developers
vis-a-vis XEmacs.  People have stronger loyalty to organizations that
espouse their ethical principles openly.  And it's easier to cooperate
with people "of your culture" because you're "getting your signals
crossed" much less frequently.

I personally don't think it would matter all that much that it would
turn the tide in the opposite direction if Emacs had another
existential crisis, but YMMV.

Sincere regards to all Emacs'ers,

Steve

Re: New maintainer

[John Wiegley]

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

> Emacs's GPL being a fact, I would hope John would keep his mouth shut about
> his disagreement while wearing his GNU Emacs maintainer hat (not limited to
> participation in Emacs lists).

I like this, Stephen. Yes, Emacs is, and likely always will be, GPL-licensed.
All my own contributions to Emacs have been under the GPL -- in order to be
compatible -- even those developments not distributed with Emacs, like the
Emacs Chess client, or use-package.

Whether I believe the GPL is a right path socially is, I think, a separate
matter from maintaining Emacs. If asked to speak about Emacs, I will speak
about Emacs. If asked to speak about the GPL, I would make it clear that my
opinions have nothing to do with Emacs, or the FSF, or any other connection
people might falsely draw due to my involvement with an FSF-sponsored project.

However, if you look at the past ten years or so of my online communications,
I've adopted a personal path of not speaking *against* anything, but rather
*for* the things that I believe in. I've come to believe that constructive
positivity is, in the end, a more fruitful path toward change than destructive
negativity -- however much I may dislike certain things in the world.

I mainly brought this up so that people would know where I stand in my
thinking, and not be surprised in the future if anyone should read all of my
old blog articles.

I'm not here to take the GPL away from anyone. I have always supported the
freedom to choose whatever path you want in life, if it does not encroach on
the freedoms of others. If the GPL is that path for you, I would defend your
right to choose it, even if I do not necessarily agree with the path you've
chosen per se.

John

Re: New maintainer

[Christopher Allan Webber]

John Wiegley writes:

>>>>>> Stephen J Turnbull <stephen@xemacs.org> writes:
>
>> Emacs's GPL being a fact, I would hope John would keep his mouth shut about
>> his disagreement while wearing his GNU Emacs maintainer hat (not limited to
>> participation in Emacs lists).
>
> I like this, Stephen. Yes, Emacs is, and likely always will be, GPL-licensed.
> All my own contributions to Emacs have been under the GPL -- in order to be
> compatible -- even those developments not distributed with Emacs, like the
> Emacs Chess client, or use-package.

This seems pretty reasonable to me, and I do think John would be an
excellent maintainer of Emacs.  Though there may be some philosophical
differences, it seems that John is willing to work within the FSF's
needs and requirements there.

John certainly knows the field can have strong guidance.  I'd look
forward to a John Wiegley maintained emacs.

 - Chris

Re: New maintainer

[David Kastrup]

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

> I disagree, as John evidently does.  By the way, if I didn't know he
> would have self-nominated if he could, I would nominate Eli Zaretskii
> as maintainer.  Do you have a problem with him?

I'd support his nomination and I don't see any current candidate that
I'd feel more comfortable with out of the box.  However, I have the
impression that Eli is more comfortable setting accents than directions,
allowing him to voice opinions stronger than if were he responsible for
setting the overall direction and atmosphere.  I'd still trust him to
work on balancing his and the project needs but am not sure how happy
he'd be with it.

-- 
David Kastrup

RE: New maintainer

[Drew Adams]

> > By the way, if I didn't know he
> > would have self-nominated if he could, I would nominate Eli Zaretskii
> > as maintainer.  Do you have a problem with him?
> 
> I'd support his nomination and I don't see any current candidate that
> I'd feel more comfortable with out of the box.  However, I have the
> impression that Eli is more comfortable setting accents than directions,
> allowing him to voice opinions stronger than if were he responsible for
> setting the overall direction and atmosphere.  I'd still trust him to
> work on balancing his and the project needs but am not sure how happy
> he'd be with it.

I too hope that Eli considers this possibility seriously.

Re: New maintainer

[Juanma Barranquero]

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

On Fri, Oct 2, 2015 at 4:07 AM, Stephen J. Turnbull <stephen@xemacs.org>
wrote:

> By the way, if I didn't know he
> would have self-nominated if he could, I would nominate Eli Zaretskii
> as maintainer.

Perhaps we could get Eli to accept co-maintainership?

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

Re: New maintainer

[Rasmus]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Fri, Oct 2, 2015 at 4:07 AM, Stephen J. Turnbull <stephen@xemacs.org>
> wrote:
>
>> By the way, if I didn't know he
>> would have self-nominated if he could, I would nominate Eli Zaretskii
>> as maintainer.
>
> Perhaps we could get Eli to accept co-maintainership?

That would indeed be very cool!

Rasmus

-- 
And I faced endless streams of vendor-approved Ikea furniture. . .

Re: New maintainer

[Karl Fogel]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
>First, I second John's self-nomination.  I suspect it's a no-op given
>his "disagreement with the spirit of the GPL", but FWIW I think he
>would be an excellent Emacs maintainer.

An important question for John is how he would feel about RMS overriding technical decisions -- that is, decisions John might feel are purely technical -- for philosophical reasons.  Can John live with that happening occasionally?  Because it surely would.

(I heartily second Stephen's second, fwiw.  John would be a great maintainer, and while I disagree with him about the GPL, I don't think that bears much on the question of whether he can maintain Emacs well, given everything else he's said here.)

Re: New maintainer

[John Wiegley]

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

> An important question for John is how he would feel about RMS overriding
> technical decisions -- that is, decisions John might feel are purely
> technical -- for philosophical reasons. Can John live with that happening
> occasionally? Because it surely would.

It has happened before: for example, Bazaar vs. Git, and not allowing dynamic
loading of libraries. Yet both of these positions changed over time. I can't
think of a "political over technical" decision right now that bothers me; and
the fact that those that did finally resolved themselves, gives me faith in
being able to work with the FSF. So yes, I can live with it happening
occasionally.

I further think that working alongside Eli would be nice, if he's up for it.
Having an active co-maintainer would relieve some of the time pressure of this
position, since I can't give equal focus every week.

John

Re: New maintainer

[Karl Fogel]

"John Wiegley" <johnw@newartisans.com> writes:
>> An important question for John is how he would feel about RMS overriding
>> technical decisions -- that is, decisions John might feel are purely
>> technical -- for philosophical reasons. Can John live with that happening
>> occasionally? Because it surely would.
>
>It has happened before: for example, Bazaar vs. Git, and not allowing dynamic
>loading of libraries. Yet both of these positions changed over time. I can't
>think of a "political over technical" decision right now that bothers me; and
>the fact that those that did finally resolved themselves, gives me faith in
>being able to work with the FSF. So yes, I can live with it happening
>occasionally.

...and that answers my question! :-)  Thank you.

>I further think that working alongside Eli would be nice, if he's up for it.
>Having an active co-maintainer would relieve some of the time pressure of this
>position, since I can't give equal focus every week.

+1 to both the general and the specific portions of that.

Re: New maintainer

[Rustom Mody]

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

On Fri, Oct 2, 2015 at 10:32 PM, John Wiegley <johnw@newartisans.com> wrote:

>
> I further think that working alongside Eli would be nice, if he's up for
> it.


A big YES from me also for this.
And thanks Stefan for showing the way
And rms for making this world for us

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

Re: New maintainer

[Óscar Fuentes]

Rustom Mody <rustompmody@gmail.com> writes:

> On Fri, Oct 2, 2015 at 10:32 PM, John Wiegley <johnw@newartisans.com> wrote:
>
>>
>> I further think that working alongside Eli would be nice, if he's up for
>> it.
>
>
> A big YES from me also for this.

Maintainers tend to burn out and eventually cease their contribution as
developers. So I wish Eli does not become a maintainer.

OTOH, appointing as maintainer someone who is not on the group of the
most active developers but respected by the community is a good deal:
that person will contribute more to Emacs than he usually does and when
he goes away the Emacs day-to-day development does not suffer.

Re: New maintainer

[Dmitry Gutov]

On 10/03/2015 03:03 PM, Óscar Fuentes wrote:

> OTOH, appointing as maintainer someone who is not on the group of the
> most active developers but respected by the community is a good deal:
> that person will contribute more to Emacs than he usually does and when
> he goes away the Emacs day-to-day development does not suffer.

+1.

Although if Eli accepts co-maintainersip only with intention to add the 
political duties of the maintainer (plus being the FSF contact) to his 
normal ones, that shouldn't be too bad.

Re: New maintainer

[Przemysław Wojnowski]

> Maintainers tend to burn out and eventually cease their contribution as
> developers.
IMHO this is very important issue to address, because with them Emacs
looses active developers and a lot of knowledge.

What can be changed in this role to not burn out people?

IMHO one problem might be that, due to lack of roadmap and clear
priorities, a lot of different things are developed at the same time,
which springs even more topics on emacs-devel. Going through this flood
and deciding on them must be tiring. Selecting top 10 (X) from the
roadmap would constrain topics range and make it simpler to manage.
Also it would clarify for developers what to focus on.

Another thing is that a maintainer doesn't have to code review every
single change (search for "the cost of perfectionism"). It's enough if
some other developer would do that.
A developer that wrote a feature can just write tests and send an email
to emacs-devel "XXX - ready for Code Review".

I don't have experience as Emacs maintainer, so I may be wrong. But I
do have some experience as a team lead and have to deal with similar
issues.

Re: New maintainer

[Eli Zaretskii]

> From: Przemysław Wojnowski <esperanto@cumego.com>
> Date: Sat, 3 Oct 2015 22:04:19 +0200
> 
> IMHO one problem might be that, due to lack of roadmap and clear
> priorities, a lot of different things are developed at the same time,

I don't think you can prevent that in a project as multi-faceted and
multi-discipline as Emacs, nor do I think you should want to.

> which springs even more topics on emacs-devel. Going through this flood
> and deciding on them must be tiring. Selecting top 10 (X) from the
> roadmap would constrain topics range and make it simpler to manage.
> Also it would clarify for developers what to focus on.

People work on the itches they want to scratch.  I think an attempt to
tell them what to do and what not to will be futile at best, and at
worst will make some go away.

> Another thing is that a maintainer doesn't have to code review every
> single change (search for "the cost of perfectionism"). It's enough if
> some other developer would do that.

Assuming those other developers indeed do that.  We have too few who
do.

> A developer that wrote a feature can just write tests and send an email
> to emacs-devel "XXX - ready for Code Review".

They already do.  Then they have to ping us weeks later.

Re: New maintainer

[Przemysław Wojnowski]

W dniu 04.10.2015 o 08:26, Eli Zaretskii pisze:
>> IMHO one problem might be that, due to lack of roadmap and clear
>> priorities, a lot of different things are developed at the same time,
>
> I don't think you can prevent that in a project as multi-faceted and
> multi-discipline as Emacs, nor do I think you should want to.
>
[...]
> People work on the itches they want to scratch.  I think an attempt to
> tell them what to do and what not to will be futile at best, and at
> worst will make some go away.

But still a roadmap, with prioritized features, would help to choose
"the itches they want to scratch". Also it would help newcomers find
out what to do.

Anyway, it was just a proposition.

The point is to find out how not too loose maintainers. If they would
step down and stay as developers would be great.
Maybe "exit interview" would help. ;-)

Re: New maintainer

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Przemysław Wojnowski <esperanto@cumego.com>
> Date: Sun, 4 Oct 2015 09:03:14 +0200
> 
> W dniu 04.10.2015 o 08:26, Eli Zaretskii pisze:
> >> IMHO one problem might be that, due to lack of roadmap and clear
> >> priorities, a lot of different things are developed at the same time,
> >
> > I don't think you can prevent that in a project as multi-faceted and
> > multi-discipline as Emacs, nor do I think you should want to.
> >
> [...]
> > People work on the itches they want to scratch.  I think an attempt to
> > tell them what to do and what not to will be futile at best, and at
> > worst will make some go away.
> 
> But still a roadmap, with prioritized features, would help to choose
> "the itches they want to scratch". Also it would help newcomers find
> out what to do.

Of course, it will.  It's a good thing to have that.  I just don't
think it could relieve the workload of the head maintainer and the
resulting burn-out, which is what you were suggesting, AFAIU.

Re: New maintainer

[Przemysław Wojnowski]

>> W dniu 04.10.2015 o 08:26, Eli Zaretskii pisze:
>>>> IMHO one problem might be that, due to lack of roadmap and clear
>>>> priorities, a lot of different things are developed at the same time,
>>>
>>> I don't think you can prevent that in a project as multi-faceted and
>>> multi-discipline as Emacs, nor do I think you should want to.
I'm not saying that people should stop work on things that would not be
on a roadmap or in the next release. My point was that there should be a 
vision of Emacs in 5-10-15 years (what we would like it to be?), a 
roadmap based on that - list of features that bring us closer to that 
vision, etc. All written down.

Based on that maintainers would be able to plan releases with features 
from a roadmap - with consensus with developers. Maybe not many features 
would make it into the next release. Maybe just one of them. But it 
would make it clear what we want and were are we going (the vision). It 
would also make developers to focus on the next release.

For new developers clear goals are very important. Nobody wants to work 
on a project that goes nowhere. There always have to be some goal.

For example I see Emacs in 5 years with strong tests that immediately 
catch bugs and make refactoring fun. To achieve that I would add a goal 
that can be started right now, especially by newcomers:
1. Write unit tests to learn how Emacs works.
It's clear, very easy to do, very good for newcomers, and brings value
to Emacs. :-)


Anyway, the beauty of Agile Software Development is its adaptability.
Such teams try different things to improve their development process.
Things that don't work are refined or rejected. It's like evolution. 
IMHO Emacs community could try to apply such process. :-)

> I just don't
> think it could relieve the workload of the head maintainer and the
> resulting burn-out, which is what you were suggesting, AFAIU.
IMHO working on a concrete release would constraint number of topics
and decisions to make, which would relieve the workload.

Here are other ideas:
1. Constraint maintenance term (for example 3 years)
Such people wouldn't be exploited and maybe would step down to
development. Of course, after that time such person can decide that
everything is ok and can be a maintainer for another X years.

IMHO having ex-maintainers still in community would help subsequent
maintainers with making hard decisions. So it would also relieve the
workload.

2. Cut off-topics and end with action items.
Cutting off-topics should be done be everyone on the list. It creates a
flood of, maybe interesting, but irrelevant to the main topic, messages.

Unrelated messages make it very hard to follow the main thread.

Even this topic has a number of unrelated threads (politics, keylogger,
mac os, compiler support, etc.). How that help to find a "New
maintainer"?


Sorry for late reply. :-|

Cheers,
Przemysław

Re: New maintainer

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Przemysław Wojnowski <esperanto@cumego.com>
> Date: Tue, 6 Oct 2015 23:58:33 +0200
> 
> >> W dniu 04.10.2015 o 08:26, Eli Zaretskii pisze:
> >>>> IMHO one problem might be that, due to lack of roadmap and clear
> >>>> priorities, a lot of different things are developed at the same time,
> >>>
> >>> I don't think you can prevent that in a project as multi-faceted and
> >>> multi-discipline as Emacs, nor do I think you should want to.
> I'm not saying that people should stop work on things that would not be
> on a roadmap or in the next release. My point was that there should be a 
> vision of Emacs in 5-10-15 years (what we would like it to be?), a 
> roadmap based on that - list of features that bring us closer to that 
> vision, etc. All written down.

I already agreed that it would be a good thing to have such a
roadmap.  But it's entirely not easy to come up with.

It's not that we didn't try before.  The best result we could come up
with is in etc/TODO.  It's an undeservedly forgotten resource.

> Based on that maintainers would be able to plan releases with features 
> from a roadmap - with consensus with developers. Maybe not many features 
> would make it into the next release. Maybe just one of them.

This assumes that there will be some sufficient correlation between
the roadmap and the significant features being developed each year.
However, such an assumption will only hold if the roadmap is
coordinated with the existing developers before it becomes official.
Otherwise, you have only luck on your side, which IME is not a good
plan.

> [roadmap] would make it clear what we want and were are we going
> (the vision). It would also make developers to focus on the next
> release.

That's the hope, but it won't happen by itself, IME.

For this reason, we have been doing until now the exact opposite:
decided on a major release when enough significant new features became
available.  I cannot say it worked badly, btw.  You can review the
major releases and see for yourself.

> Nobody wants to work on a project that goes nowhere. There always
> have to be some goal.

I don't think there could be _a_ goal for Emacs.  It will always be
quite a few significant ones, and then many more less significant, but
still important ones.  In this sense, there's no single direction in
which Emacs is, or should be going.

> For example I see Emacs in 5 years with strong tests that immediately 
> catch bugs and make refactoring fun. To achieve that I would add a goal 
> that can be started right now, especially by newcomers:
> 1. Write unit tests to learn how Emacs works.
> It's clear, very easy to do, very good for newcomers, and brings value
> to Emacs. :-)

And it's already in etc/TODO, not very far from its beginning.

Besides, "more tests" is hardly a development direction, it's a means
to an end.

> Anyway, the beauty of Agile Software Development is its adaptability.
> Such teams try different things to improve their development process.
> Things that don't work are refined or rejected. It's like evolution. 
> IMHO Emacs community could try to apply such process. :-)

Reality check: we are not a team, in the Agile development sense.

> > I just don't
> > think it could relieve the workload of the head maintainer and the
> > resulting burn-out, which is what you were suggesting, AFAIU.
> IMHO working on a concrete release would constraint number of topics
> and decisions to make, which would relieve the workload.

I don't believe we will be able to constrain contributors to "working
on a release".  Just watch the pressure we have every time we declare
a feature freeze to cut a release branch and end the freeze.

> Here are other ideas:
> 1. Constraint maintenance term (for example 3 years)

No need.  Someone who feels burnt out will step down.  Someone who
don't, and does a good job, should be allowed to proceed.

> 2. Cut off-topics and end with action items.
> Cutting off-topics should be done be everyone on the list. It creates a
> flood of, maybe interesting, but irrelevant to the main topic, messages.

This is not a job with bosses and employees.  There are no means for
anyone here, including the head maintainer, to shut anyone up or force
them to stop discussing something.  Trying to do that wastes energy
and does little else.

> Unrelated messages make it very hard to follow the main thread.

Yes, liberal democracy is the worst of all regimes, except for all the
rest.

> Even this topic has a number of unrelated threads (politics, keylogger,
> mac os, compiler support, etc.). How that help to find a "New
> maintainer"?

There's nothing you can do against that.

Re: New maintainer

[Malk'Zameth]

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

Hi all,

Pardon my ignorance and, I presume my raging naïveté possible only out of a
lack of the whole context, here
(if answering me would derail the subject, please ignore)

1 - the GCCvsClang issue touches features of Emacs itself (impacting 100%
of Emacsers) or just people using GCC/Clang for dev?

2 - If the latter: If we where to move CC-mode from the emacs core to Elpa
would that cut the debate from the core Emacs point of view?

we have an amazing module/package system now right? And probably the C devs
are no longer the majority ?

3 - On more abstract level: If we where, hypothetically, to slim down the
Core Emacs as much as possible and rely heavily on the packaging system
itself: what contention points between Freedom and Technical Evolution
would remain on the core itself?

Thanks,

Romeu


On Wed, Oct 7, 2015 at 5:27 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > Cc: emacs-devel@gnu.org
> > From: Przemysław Wojnowski <esperanto@cumego.com>
> > Date: Tue, 6 Oct 2015 23:58:33 +0200
> >
> > >> W dniu 04.10.2015 o 08:26, Eli Zaretskii pisze:
> > >>>> IMHO one problem might be that, due to lack of roadmap and clear
> > >>>> priorities, a lot of different things are developed at the same
> time,
> > >>>
> > >>> I don't think you can prevent that in a project as multi-faceted and
> > >>> multi-discipline as Emacs, nor do I think you should want to.
> > I'm not saying that people should stop work on things that would not be
> > on a roadmap or in the next release. My point was that there should be a
> > vision of Emacs in 5-10-15 years (what we would like it to be?), a
> > roadmap based on that - list of features that bring us closer to that
> > vision, etc. All written down.
>
> I already agreed that it would be a good thing to have such a
> roadmap.  But it's entirely not easy to come up with.
>
> It's not that we didn't try before.  The best result we could come up
> with is in etc/TODO.  It's an undeservedly forgotten resource.
>
> > Based on that maintainers would be able to plan releases with features
> > from a roadmap - with consensus with developers. Maybe not many features
> > would make it into the next release. Maybe just one of them.
>
> This assumes that there will be some sufficient correlation between
> the roadmap and the significant features being developed each year.
> However, such an assumption will only hold if the roadmap is
> coordinated with the existing developers before it becomes official.
> Otherwise, you have only luck on your side, which IME is not a good
> plan.
>
> > [roadmap] would make it clear what we want and were are we going
> > (the vision). It would also make developers to focus on the next
> > release.
>
> That's the hope, but it won't happen by itself, IME.
>
> For this reason, we have been doing until now the exact opposite:
> decided on a major release when enough significant new features became
> available.  I cannot say it worked badly, btw.  You can review the
> major releases and see for yourself.
>
> > Nobody wants to work on a project that goes nowhere. There always
> > have to be some goal.
>
> I don't think there could be _a_ goal for Emacs.  It will always be
> quite a few significant ones, and then many more less significant, but
> still important ones.  In this sense, there's no single direction in
> which Emacs is, or should be going.
>
> > For example I see Emacs in 5 years with strong tests that immediately
> > catch bugs and make refactoring fun. To achieve that I would add a goal
> > that can be started right now, especially by newcomers:
> > 1. Write unit tests to learn how Emacs works.
> > It's clear, very easy to do, very good for newcomers, and brings value
> > to Emacs. :-)
>
> And it's already in etc/TODO, not very far from its beginning.
>
> Besides, "more tests" is hardly a development direction, it's a means
> to an end.
>
> > Anyway, the beauty of Agile Software Development is its adaptability.
> > Such teams try different things to improve their development process.
> > Things that don't work are refined or rejected. It's like evolution.
> > IMHO Emacs community could try to apply such process. :-)
>
> Reality check: we are not a team, in the Agile development sense.
>
> > > I just don't
> > > think it could relieve the workload of the head maintainer and the
> > > resulting burn-out, which is what you were suggesting, AFAIU.
> > IMHO working on a concrete release would constraint number of topics
> > and decisions to make, which would relieve the workload.
>
> I don't believe we will be able to constrain contributors to "working
> on a release".  Just watch the pressure we have every time we declare
> a feature freeze to cut a release branch and end the freeze.
>
> > Here are other ideas:
> > 1. Constraint maintenance term (for example 3 years)
>
> No need.  Someone who feels burnt out will step down.  Someone who
> don't, and does a good job, should be allowed to proceed.
>
> > 2. Cut off-topics and end with action items.
> > Cutting off-topics should be done be everyone on the list. It creates a
> > flood of, maybe interesting, but irrelevant to the main topic, messages.
>
> This is not a job with bosses and employees.  There are no means for
> anyone here, including the head maintainer, to shut anyone up or force
> them to stop discussing something.  Trying to do that wastes energy
> and does little else.
>
> > Unrelated messages make it very hard to follow the main thread.
>
> Yes, liberal democracy is the worst of all regimes, except for all the
> rest.
>
> > Even this topic has a number of unrelated threads (politics, keylogger,
> > mac os, compiler support, etc.). How that help to find a "New
> > maintainer"?
>
> There's nothing you can do against that.
>
>
>

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

Re: New maintainer

[Eli Zaretskii]

> From: "Malk'Zameth" <malk@zameth.org>
> Date: Wed, 7 Oct 2015 18:47:39 +0200
> Cc: emacs-devel@gnu.org
> 
> 1 - the GCCvsClang issue touches features of Emacs itself (impacting 100% of
> Emacsers) or just people using GCC/Clang for dev?

Anyone who wants an IDE for languages supported by GCC (not just C).

> 2 - If the latter: If we where to move CC-mode from the emacs core to Elpa
> would that cut the debate from the core Emacs point of view?

No, because ELPA is for all practical purposes part of Emacs.

> we have an amazing module/package system now right? And probably the C devs are
> no longer the majority ?

GCC supports more than just C, and C++ is still a very popular
development language.

> 3 - On more abstract level: If we where, hypothetically, to slim down the Core
> Emacs as much as possible and rely heavily on the packaging system itself: what
> contention points between Freedom and Technical Evolution would remain on the
> core itself?

All of it.

Re: New maintainer

[Artur Malabarba]

I'm not going to dive into GCC/Clang discussion, but I think I can
answer your questions.

2015-10-07 17:47 GMT+01:00 Malk'Zameth wrote:

> 1 - the GCCvsClang issue touches features of Emacs itself (impacting 100% of
> Emacsers) or just people using GCC/Clang for dev?

IIUC, People using GCC/Clang.

> 2 - If the latter: If we where to move CC-mode from the emacs core to Elpa
> would that cut the debate from the core Emacs point of view?

No. GNU Elpa is part of Emacs in pretty much every sense. It's not
(currently) bundled in the tarball, but other than that it _is_ Emacs
(and is bound by all the same rules).

> we have an amazing module/package system now right? And probably the C devs
> are no longer the majority ?

I have no numbers, but my guess is that no single language holds the
majority of the Emacs user base. Emacs has a pretty wide spread from
what I can tell.

But, given my answer above, this is besides the point. :-)

> 3 - On more abstract level: If we where, hypothetically, to slim down the
> Core Emacs as much as possible and rely heavily on the packaging system
> itself: what contention points between Freedom and Technical Evolution would
> remain on the core itself?

Don't know, but it's besides the point again. Any contention points
moved to Elpa would still be contention points.

Re: New maintainer

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > 2 - If the latter: If we where to move CC-mode from the emacs core to Elpa
  > would that cut the debate from the core Emacs point of view?

The issue is one of substance, not just labeling.  Moving CC mode
(which is used for various languages, not just C) would not change
the substance.


-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: New maintainer

[Przemysław Wojnowski]

W dniu 07.10.2015 o 17:27, Eli Zaretskii pisze:
> It's not that we didn't try before.  The best result we could come up
> with is in etc/TODO.  It's an undeservedly forgotten resource.
Didn't know that such file exist. Thanks!
It definitely should have more exposure, especially "Simple tasks"
section. How about mentioning it in etc/CONTRIBUTE?.

What I found strange is that the following file has different content:
http://www.gnu.org/software/emacs/CONTRIBUTE

>> Based on that maintainers would be able to plan releases with features
>> from a roadmap - with consensus with developers. Maybe not many features
>> would make it into the next release. Maybe just one of them.
>
> This assumes that there will be some sufficient correlation between
> the roadmap and the significant features being developed each year.
> However, such an assumption will only hold if the roadmap is
> coordinated with the existing developers before it becomes official.
Yes. Keep in mind that nothing is welded and can change for various 
reason, the roadmap too. But at least it's a plan (starting point).

>> [roadmap] would make it clear what we want and were are we going
>> (the vision). It would also make developers to focus on the next
>> release.
>
> That's the hope, but it won't happen by itself, IME.
>
> For this reason, we have been doing until now the exact opposite:
> decided on a major release when enough significant new features became
> available.  I cannot say it worked badly, btw.  You can review the
> major releases and see for yourself.
Maybe it's a good approach.

>> Nobody wants to work on a project that goes nowhere. There always
>> have to be some goal.
>
> I don't think there could be _a_ goal for Emacs.  It will always be
> quite a few significant ones, and then many more less significant, but
> still important ones.  In this sense, there's no single direction in
> which Emacs is, or should be going.
Well, IMHO some goals could be defined, for example "Provide IDE
features for language X (maybe unified) to make a programmer
productive". To achieve that some smaller goals would need to be
achieved, for example:
- provide project support (notion of project, maybe unified project API
   for different languages, debugger, etc.)
- provide refactoring tools for language(s) X (Y/Z)
- etc.

It could be divided into yet smaller goals until they finish in "Simple
tasks" section . ;-)

>> [...] strong tests

>> 1. Write unit tests to learn how Emacs works.
>> It's clear, very easy to do, very good for newcomers, and brings value
>> to Emacs. :-)
It was not a joke. Writing tests is a very good way to learn how things
work.

> Besides, "more tests" is hardly a development direction, it's a means
> to an end.
I've written "strong tests", which is not the same. But to be clear,
the goal is to have enough test to change Emacs safely, without a fear
of introducing new bugs (of course that will always happen, but with
"strong tests" they are very limited). Such tests allow to build
deployment pipeline and be able to release Emacs on every commit that
pass the pipeline. IMHO this can be a goal.

>
>> Anyway, the beauty of Agile Software Development is its adaptability.
>> Such teams try different things to improve their development process.
>> Things that don't work are refined or rejected. It's like evolution.
>> IMHO Emacs community could try to apply such process. :-)
>
> Reality check: we are not a team, in the Agile development sense.
Yes. The point here is constant improvement. Being open on new things ,
trying them and adapting what works. It doesn't have to be constrained
only to the Agile teams.

>>> I just don't
>>> think it could relieve the workload of the head maintainer and the
>>> resulting burn-out, which is what you were suggesting, AFAIU.
>> IMHO working on a concrete release would constraint number of topics
>> and decisions to make, which would relieve the workload.
>
> I don't believe we will be able to constrain contributors to "working
> on a release".  Just watch the pressure we have every time we declare
> a feature freeze to cut a release branch and end the freeze.
Maybe you're right. It was just an idea.

>> Here are other ideas:
>> 1. Constraint maintenance term (for example 3 years)
> No need.  Someone who feels burnt out will step down.  Someone who
> don't, and does a good job, should be allowed to proceed.
Maybe. It was just an idea how not to loose valuable people. Maybe
someone else will have a better one.

>> 2. Cut off-topics and end with action items.
>> Cutting off-topics should be done be everyone on the list. It creates a
>> flood of, maybe interesting, but irrelevant to the main topic, messages.
>
> This is not a job with bosses and employees.  There are no means for
> anyone here, including the head maintainer, to shut anyone up or force
> them to stop discussing something.  Trying to do that wastes energy
> and does little else.
Sorry. Seems that there's a misunderstanding. I don't want to "shut up"
anyone, but just ask for moving "off-topics" to new threads - "Please
discuss X in a separate thread."

>> Unrelated messages make it very hard to follow the main thread.
>> Even this topic has a number of unrelated threads (politics, keylogger,
>> mac os, compiler support, etc.). How that help to find a "New
>> maintainer"?
>
> There's nothing you can do against that.
Well, I can ask to discuss other topics in a new threads. Being polite
doesn't hurt.

Cheers,
Przemysław

Re: New maintainer

[Eli Zaretskii]

> From: Przemysław Wojnowski <esperanto@cumego.com>
> Date: Wed, 7 Oct 2015 20:49:39 +0200
> Cc: emacs-devel@gnu.org
> 
> W dniu 07.10.2015 o 17:27, Eli Zaretskii pisze:
> > It's not that we didn't try before.  The best result we could come up
> > with is in etc/TODO.  It's an undeservedly forgotten resource.
> Didn't know that such file exist. Thanks!
> It definitely should have more exposure, especially "Simple tasks"
> section. How about mentioning it in etc/CONTRIBUTE?.

It is already, indirectly, via a pointer to (info "(emacs)Contributing").

> What I found strange is that the following file has different content:
> http://www.gnu.org/software/emacs/CONTRIBUTE

The documentation Web site tracks the released versions, not the
development master branch.  See etc/CONTRIBUTE in Emacs 24.5.

Re: New maintainer

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

A roadmap is a useful thing for the maintainers to develop.
That doesn't mean they should reject improvements that are
outside the roadmap.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: New maintainer

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

One thing the maintainer might do, when people launch many tangents on
the list, is to pick one topic to discuss first and tell people to
save the others for later.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: New maintainer

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

GNU Emacs is part of the GNU Project, which is a technical project
with a specific political aim: software freedom for all users.  This
goal includes all the software they use, not just the specific programs
we develop.

The GNU Emacs maintainer's responsibility is to take charge of Emacs
on behalf of the GNU Project, and produce the best possible GNU Emacs
-- which means, the one that advances our aim the most.

Mostly, making Emacs better is a matter of practical improvements, but
there are some exceptions.  The maintainer's responsibility includes
some tasks to support the GPL, both practically and politically.  It
includes getting copyright papers from contributors so we can enforce
the GPL.  It includes making sure dynamic loading resists GPL
violation.  It includes putting some GNU Project political statements
into Emacs.  It includes making sure nothing in Emacs disagrees with
them.  An Emacs maintainer has to be willing to undertake this part of
the responsibility as well as the politically neutral bulk of the
responsibility.

The maintainer's job does not include personal political statements.
Maintainers don't have to say they agree with the GNU Project's
political positions, they just have to implement them wholeheartedly.

However, a maintainer shouldn't publicly oppose our positions.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: New maintainer

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Fri, 02 Oct 2015 21:36:28 -0400
> Cc: emacs-devel@gnu.org
> 
> GNU Emacs is part of the GNU Project, which is a technical project
> with a specific political aim: software freedom for all users.  This
> goal includes all the software they use, not just the specific programs
> we develop.
> 
> The GNU Emacs maintainer's responsibility is to take charge of Emacs
> on behalf of the GNU Project, and produce the best possible GNU Emacs
> -- which means, the one that advances our aim the most.
> 
> Mostly, making Emacs better is a matter of practical improvements, but
> there are some exceptions.  The maintainer's responsibility includes
> some tasks to support the GPL, both practically and politically.  It
> includes getting copyright papers from contributors so we can enforce
> the GPL.  It includes making sure dynamic loading resists GPL
> violation.  It includes putting some GNU Project political statements
> into Emacs.  It includes making sure nothing in Emacs disagrees with
> them.  An Emacs maintainer has to be willing to undertake this part of
> the responsibility as well as the politically neutral bulk of the
> responsibility.
> 
> The maintainer's job does not include personal political statements.
> Maintainers don't have to say they agree with the GNU Project's
> political positions, they just have to implement them wholeheartedly.
> 
> However, a maintainer shouldn't publicly oppose our positions.

Thanks for that summary, Richard.

In my personal experience, what you describe is not the most important
part of the decision a candidate or a nominee should make before
agreeing to volunteer.  He or she should indeed make sure they are OK
with all of the above, but I believe most of us are anyway.  The
practical implications of the above are more or less no-brainers:
performing the few implied duties is simple, even mechanical, and some
of them will rarely if ever be needed at all, except in some extreme
and improbable situation (like if someone declares they no longer want
to be part of the GNU Project, forks Emacs and takes most of the
contributors with them).  Yet another part is just agreement to some
principles, and has not practical implications beyond the fact of the
agreement itself.

IOW, this, what I call "the FSF side", of being the maintainer is not
the hard part of the decision to become one, nor something most of the
others should consider when they decide whether a candidate gets their
vote of confidence.  The hard part, IMO, is what does it mean "to
produce the best possible Emacs"?  What's the translation of this to
everyday's practice?

Perhaps we should consider this part of the job description before we
start nominating candidates and volunteering.

Emacs is so large that its maintenance is IMO qualitatively different
from almost any other package out there.  There are maybe a dozen
distinct large areas of expertise in the C core, dozens of such areas
in core Lisp infrastructures, and hundreds of them on the application
level.  Each one of these comes with its own non-trivial
domain-specific knowledge, its own algorithms, its own do's and
dont's.  No single person nor a small (2-3) number of people could
ever cover all that turf in any reasonable way.

By contrast, a head maintainer seems to be expected to be the final
authority for making decisions on changes in any particular area, and
also on design and implementation of both significant and
insignificant new features.

So, given this seemingly unsolvable contradiction, what do you, the
crowd, expect of the new maintainer?  What "job description", in
addition to what Richard wrote, would you propose if you were tasked
with the job of finding the candidates?  E.g., how many hours a week
should that person be available for working on Emacs?  Which talents
and personal traits should he or she possess?  Etc. etc.

I'm not writing this to solicit a barrage of suggestions for such a
job description, so please hold off your fast-typing fingers.  I'm
writing this to suggest that each one of us should take a moment to
think about these expectations, and decide who or what would we want
that next "maintainer" to be.  That's because I'm not sure all of
those who participated in this thread have the same things in mind
when they express their opinions about who might be a good maintainer.
Then look around and see if there are any persons who fit the bill
here.  Then you could perhaps provide some rationale for why you think
this or that person could be a good candidate.

HTH

Re: New maintainer

[Xue Fuqiao]

On Sat, Oct 3, 2015 at 4:04 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> Emacs is so large that its maintenance is IMO qualitatively different
> from almost any other package out there.  There are maybe a dozen
> distinct large areas of expertise in the C core, dozens of such areas
> in core Lisp infrastructures, and hundreds of them on the application
> level.  Each one of these comes with its own non-trivial
> domain-specific knowledge, its own algorithms, its own do's and
> dont's.  No single person nor a small (2-3) number of people could
> ever cover all that turf in any reasonable way.
>
> By contrast, a head maintainer seems to be expected to be the final
> authority for making decisions on changes in any particular area, and
> also on design and implementation of both significant and
> insignificant new features.
>
> So, given this seemingly unsolvable contradiction, what do you, the
> crowd, expect of the new maintainer?  What "job description", in
> addition to what Richard wrote, would you propose if you were tasked
> with the job of finding the candidates?  E.g., how many hours a week
> should that person be available for working on Emacs?  Which talents
> and personal traits should he or she possess?  Etc. etc.

The head maintainer should make policy about the general direction of
Emacs, and should make final decisions.

Since one single maintainer or a small team can't "cover all that turf",
the decision-making can be distributed to a range of participants.  I
think a (documented) decision-making policy would be nice.  When a new
idea, feature, patch, etc. turns up in the mailing lists (most likely on
emacs-devel), voting, for example, can be helpful for gauging the
community's general sentiment, or help the head maintainer make a
decision if he or she is not familiar with the domain-specific knowledge
of a package/area.  It doesn't have to have a binding force.  Voting can
be done with numbers (+1, -1, 0), and a -1 vote should include an
alternative proposal or a detailed explanation of the reasons for the
vote.  Of course, to provide an opportunity for participants from all
over the world, there should be a minimum voting duration (e.g., 72
hours).  But IMHO using a vote tracking system like Debian's devotee[1]
is overkill.

Or, the head maintainer only makes a decision when:
* it needs urgent action
* nobody else has responsibility (perhaps judged by `admin/MAINTAINERS'
  and/or the `Maintainer' header in a file)
* we can't reach an agreement

As for "job description", in addition to what Richard wrote, I think the
head maintainer should also:
* know the overall situation of Emacs well
* be familiar enough with Emacs Lisp, C, and Git
* be comfortable with Debbugs (or be willing to find a good alternative
  that can still be controlled with email and write import scripts from
  Debbugs and assist its deployment inside the FSF infrastructure)
* be comfortable with Texinfo
* (at least) have some basic understanding of the GNU build system
* keep an eye on GNU ELPA commits, not only Emacs core

Moreover, IMO if an Emacs developer nominate herself as a candidate head
maintainer, she should summarize her plans for her term.  For example,
if I self-nominate for that role, I'll write something about how to make
Emacs easier to contribute, the release schedule, when to
obsolete/deprecate features, how to improve the bug-fixing workflow and
the testing infrastructure, how to cooperate/communicate better with
popular third-party packages (like Magit/CIDER/Projectile), and write a
draft feature roadmap (dynload/modules, concurrency, new extension
languages, FFI, i18n, GUI builder, etc.).

[1] https://www.debian.org/vote/

Re: New maintainer

[David Engster]

Eli Zaretskii writes:
> So, given this seemingly unsolvable contradiction, what do you, the
> crowd, expect of the new maintainer?

That he actually wants the job. Since we seem to be in the 'zero
candidates' phase again, I have a hunch that this will be the biggest
hurdle. I don't think that formulating a job description will be a good
way of getting people to step up as candidates, as it will most likely
look pretty daunting.

-David

Re: New maintainer

[Eli Zaretskii]

> From: David Engster <deng@randomsample.de>
> Cc: rms@gnu.org,  johnw@newartisans.com,  emacs-devel@gnu.org
> Date: Sat, 03 Oct 2015 21:47:58 +0200
> 
> Eli Zaretskii writes:
> > So, given this seemingly unsolvable contradiction, what do you, the
> > crowd, expect of the new maintainer?
> 
> That he actually wants the job.

What job is that?  What does it entail?

> I don't think that formulating a job description will be a good way
> of getting people to step up as candidates, as it will most likely
> look pretty daunting.

So you expect someone to volunteer without knowing what's expected
from them?  I'd say "good luck with that", but I very much hope to be
proved wrong.

Re: New maintainer

[David Engster]

Eli Zaretskii writes:
>> From: David Engster <deng@randomsample.de>
>> Cc: rms@gnu.org,  johnw@newartisans.com,  emacs-devel@gnu.org
>> Date: Sat, 03 Oct 2015 21:47:58 +0200
>> 
>> Eli Zaretskii writes:
>> > So, given this seemingly unsolvable contradiction, what do you, the
>> > crowd, expect of the new maintainer?
>> 
>> That he actually wants the job.
>
> What job is that?  What does it entail?

I think the new head maintainer should already have an idea what it
entails, simply by following emacs-devel and the bug tracker and
contributing to Emacs. It's not like Stefan did his work in secret.

-David

Re: New maintainer

[John Wiegley]

>>>>> David Engster <deng@randomsample.de> writes:

> I think the new head maintainer should already have an idea what it entails,
> simply by following emacs-devel and the bug tracker and contributing to
> Emacs. It's not like Stefan did his work in secret.

Very good point.

John

Re: New maintainer

[Mathieu Lirzin]

Richard Stallman <rms@gnu.org> writes:

> The GNU Emacs maintainer's responsibility is to take charge of Emacs
> on behalf of the GNU Project, and produce the best possible GNU Emacs
> -- which means, the one that advances our aim the most.
                                        ^^^
> Mostly, making Emacs better is a matter of practical improvements, but
> there are some exceptions.  The maintainer's responsibility includes
> some tasks to support the GPL, both practically and politically.  It
> includes getting copyright papers from contributors so we can enforce
                                                         ^^
> the GPL.  It includes making sure dynamic loading resists GPL
> violation.  It includes putting some GNU Project political statements
> into Emacs.  It includes making sure nothing in Emacs disagrees with
> them.  An Emacs maintainer has to be willing to undertake this part of
> the responsibility as well as the politically neutral bulk of the
> responsibility.
>
> The maintainer's job does not include personal political statements.
> Maintainers don't have to say they agree with the GNU Project's
> political positions, they just have to implement them wholeheartedly.
>
> However, a maintainer shouldn't publicly oppose our positions.
                                                  ^^^

My overall feeling of your description of the Emacs maintainer's role is
that it consists of practical improvements with political obligations,
and no vocal disagreement with “us”.  This gives me the impression that
you consider GNU package maintainers as separate from the GNU project
itself.  But who is that “We” if it doesn't include the maintainers?

--
Mathieu Lirzin

Re: New maintainer

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    > But who is that “We” if it doesn't include the maintainers?

I founded the GNU Project in 1983 with a specific technical goal and a
specific political purpose.  I am its leader, though others help
manage it.  I say "we" when I speak for the project rather than for
myself personally.

GNU package maintainers undertake to maintain specific packages
on behalf of the GNU Project.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: New maintainer

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Using MacOSX & iOS as main operating systems and Hangout/Skype for
  > communications, seems incompatible with the role to me.

The Emacs maintainers should never ask contributors to use any of
those things.  What they personally use is a different issue.
It is very desirable for the main Emacs maintainer to use GNU/Linux,
since that is the principal target platform for GNU Emacs.
However, a person who uses some other system can still be a good
comaintainer.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: New maintainer

[Lennart Borgman]

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

On Tue, Sep 29, 2015 at 11:46 PM, John Wiegley <johnw@newartisans.com>
wrote:

> >>>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> > So, now that I stepped down, we need to find a new maintainer (or a new
> > maintainer-team).
>
> I'd like to self-nominate for that role, Stefan. I've been contributing to
> Emacs since 1994, and have loved it all the while. Emacs Lisp remains a
> very
> enjoyable language to write certain types of code in.
>
> Some things I'd like to see happen to Emacs are more efficiency, closing
> bugs,
> and wider adoption of some of our newest features, like lexical scoping.
> That
> said, I'm also excited by new prospects, and wonder what can be done in the
> area of concurrency (in some form), a new language under the hood (Guile?),
> etc.
>
> Emacs is my favorite application, by far, and the one I spend the most time
> in, both professionally and personally. It's my programming environment,
> E-mail reader, IRC client, task manager, note taker, and occasional shell.
> I'm
> hoping it will still be the best choice for these things after twenty
> _more_
> years of use, and perhaps as head maintainer I could help keep things
> moving
> in that direction.
>
> John
>
>
I am glad to see you want to do the job!

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

Re: New maintainer

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Being the Emacs maintainer (or a comaintainer) is a different job from
developing Emacs (although normally the maintainer also participates
in development).  The maintainer is in charge of Emacs development on
behalf of the GNU Project.  The maintainer's job is to manage the
development, not necessarily to do it.

I think that two maintainers would be ideal, but three could work.
More than that would be difficult as it would be hard for them
to make decisions together.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: New maintainer

[David De La Harpe Golden]

On 02/10/15 03:24, Richard Stallman wrote:
 > I think that two maintainers would be ideal, but three could work.
 > More than that would be difficult as it would be hard for them
 > to make decisions together.
 >

Regardin two vs three, note a Triumvirate can be better in that 
particular respect. If each person has one "vote", and they're deciding 
on a binary issue, then two people can deadlock, three can't.


1	2	result
No	No	No
No	Yes	Civil War
Yes	No	Civil War
Yes	Yes	Yes


1	2	3	result
No	No	No	No
No	No	Yes	No
No	Yes	No	No
No	Yes	Yes	Yes
Yes	No	No	No
Yes	No	Yes	Yes
Yes	Yes	No	Yes
Yes	Yes	Yes	Yes

Re: New maintainer

[Eli Zaretskii]

> Date: Sat, 03 Oct 2015 19:37:46 +0100
> From: David De La Harpe Golden <david@harpegolden.net>
> 
> Regardin two vs three, note a Triumvirate can be better in that 
> particular respect. If each person has one "vote", and they're deciding 
> on a binary issue, then two people can deadlock, three can't.

Why do you assume that majority voting is the only possible way of
making decisions?

Re: New maintainer

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> Why do you assume that majority voting is the only possible way of making
> decisions?

It's the only way to break a tie if there is vehement difference of opinion. I
didn't say it was the only way to make decisions.

John

Re: New maintainer

[John Wiegley]

>>>>> John Wiegley <johnw@newartisans.com> writes:

> It's the only way to break a tie if there is vehement difference of opinion.
> I didn't say it was the only way to make decisions.

There's another reason not to use a Cabal-of-3, though, Eli: it would mean
always waiting until you could consult with the other 2 before making
pronouncements about direction on the mailing list. Otherwise, you risk the
possibility of deciding something that the other two don't agree with. This
would add unnecessary inertia to the process, in my opinion.

I say this having participated in group-driven scenarios before. It does slow
things down, since you have to communicate first with the group (either on or
off list), and then with the community. And there's the matter of presenting a
united front, being clear on what is personal opinion and what is the opinion
of the group, etc.

John

Re: New maintainer

[Eli Zaretskii]

> From: John Wiegley <johnw@newartisans.com>
> Date: Sat, 03 Oct 2015 12:12:42 -0700
> 
> >>>>> John Wiegley <johnw@newartisans.com> writes:
> 
> > It's the only way to break a tie if there is vehement difference of opinion.
> > I didn't say it was the only way to make decisions.
> 
> There's another reason not to use a Cabal-of-3, though, Eli: it would mean
> always waiting until you could consult with the other 2 before making
> pronouncements about direction on the mailing list. Otherwise, you risk the
> possibility of deciding something that the other two don't agree with. This
> would add unnecessary inertia to the process, in my opinion.

What's the rush?  This isn't some military operation we are planning,
where any delay might cause a catastrophe.

Besides, I see no reason to believe that any of the maintainers would
become incommunicado for long periods without an advance warning.
Being available on short notice should be part of the job description.

> I say this having participated in group-driven scenarios before. It does slow
> things down, since you have to communicate first with the group (either on or
> off list), and then with the community. And there's the matter of presenting a
> united front, being clear on what is personal opinion and what is the opinion
> of the group, etc.

The good feeling of being part of the team and having your opinions
heard and seriously considered, rather than dismissed, might be worth
the delay.

Re: New maintainer

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> The good feeling of being part of the team and having your opinions heard
> and seriously considered, rather than dismissed, might be worth the delay.

Perhaps so, I could be convinced I'm wrong on this point.

John

Re: New maintainer

[Eli Zaretskii]

> From: "John Wiegley" <johnw@newartisans.com>
> Date: Sat, 03 Oct 2015 12:08:21 -0700
> 
> >>>>> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Why do you assume that majority voting is the only possible way of making
> > decisions?
> 
> It's the only way to break a tie if there is vehement difference of
> opinion.

No, it isn't.  It's just one way.  One obvious alternative is to look
for a compromise that everyone can live with.  And there are others.

Re: New maintainer

[John Wiegley]

>>>>> David De La Harpe Golden <david@harpegolden.net> writes:

> Regardin two vs three, note a Triumvirate can be better in that particular
> respect. If each person has one "vote", and they're deciding on a binary
> issue, then two people can deadlock, three can't.

I appreciate the logic of this, but I think real leadership means having a
head maintainer, and a supporting co-maintainer, so that the head can always
have final decision on matters relating to direction. Otherwise, you risk
inconsistency or disgruntlement when something truly important to one
maintainer is voted down by the other two.

In short, you either trust the person you're giving primary reins to, or you
do not. Making it a rule-by-committee is not necessarily going to give you a
"three minds are better than one" result.

John

Re: New maintainer

[Eli Zaretskii]

> From: "John Wiegley" <johnw@newartisans.com>
> Date: Sat, 03 Oct 2015 11:59:12 -0700
> 
> I think real leadership means having a head maintainer, and a
> supporting co-maintainer, so that the head can always have final
> decision on matters relating to direction.

How would such an arrangement differ from having just that head as a
single maintainer?  What can the co-maintainer do that the rest of us
cannot?

Re: New maintainer

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> How would such an arrangement differ from having just that head as a single
> maintainer? What can the co-maintainer do that the rest of us cannot?

The co-maintainer is usually given full maintainership over pieces of the
puzzle he (or she) has expertise with, until such time that the head
maintainer feels a unified direction is no longer being pursued. If there is
commonality of thought between them, they typically act in concert and most
people wouldn't realize that one of them has final decision.

Ensuring that one person sets the tone and vision for progress ensures that
things are never paralyzed by in-fighting or disagreement. If the
co-maintainer has issues with the maintainer, he resigns; if the maintainer
has issues with the co-maintainer, he asks him to step down.

John

Re: New maintainer

[Eli Zaretskii]

> From: John Wiegley <johnw@newartisans.com>
> Date: Sat, 03 Oct 2015 12:19:57 -0700
> 
> >>>>> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > How would such an arrangement differ from having just that head as a single
> > maintainer? What can the co-maintainer do that the rest of us cannot?
> 
> The co-maintainer is usually given full maintainership over pieces of the
> puzzle he (or she) has expertise with, until such time that the head
> maintainer feels a unified direction is no longer being pursued.

That's the situation with every non-maintainer here: they are free to
do whatever they feel like in the areas they are interested in, with
the head maintainer keeping an eye on their commits and asking them to
make changes where he/she doesn't like the results.

I don't see how what you describe is any different.

> If there is commonality of thought between them, they typically act
> in concert and most people wouldn't realize that one of them has
> final decision.

Of course, they will realize: if nothing else, that fact is announced
up front.  And even if someone misses that announcement, it becomes
crystal clear very soon.

Anyway, if there are never any differences of opinions (and I think
it's naïve to expect that), then you have in effect a single person,
not 2 or 3.  In which case there's no real meaning to being the head,
is there?

> Ensuring that one person sets the tone and vision for progress ensures that
> things are never paralyzed by in-fighting or disagreement. If the
> co-maintainer has issues with the maintainer, he resigns; if the maintainer
> has issues with the co-maintainer, he asks him to step down.

I don't think this could ever work well in a project such as Emacs.
How can the head set the tone and vision, when he/she is not expert
enough in at least a few of the core areas?  If you want to set the
tone and vision in the development of the area of my expertise --
let's take the support for bidirectional editing as a good example --
don't you need me to first teach you enough about that, so you could
make up your own mind, instead of just trusting me?  And if you are
afraid of "issues" between us (i.e. you don't really trust me 100%),
why would you believe that I'll make an unbiased presentation of what
you need to learn, rather than bias it a bit to ensure that you agree
with me?

I think this method will encourage in-fighting and "bad blood", not
play them down.

Re: New maintainer

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> I don't think this could ever work well in a project such as Emacs. How can
> the head set the tone and vision, when he/she is not expert enough in at
> least a few of the core areas? If you want to set the tone and vision in the
> development of the area of my expertise -- let's take the support for
> bidirectional editing as a good example -- don't you need me to first teach
> you enough about that, so you could make up your own mind, instead of just
> trusting me? And if you are afraid of "issues" between us (i.e. you don't
> really trust me 100%), why would you believe that I'll make an unbiased
> presentation of what you need to learn, rather than bias it a bit to ensure
> that you agree with me?

I'm not sure it's worth derailing this thread to argue these things. Let them
find some new maintainer(s), and those candidates can work out with the FSF
whatever arrangement they prefer.

John

Re: New maintainer

[Andreas Röhler]

Am 03.10.2015 um 22:04 schrieb John Wiegley:
>>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>> I don't think this could ever work well in a project such as Emacs. How can
>> the head set the tone and vision, when he/she is not expert enough in at
>> least a few of the core areas? If you want to set the tone and vision in the
>> development of the area of my expertise -- let's take the support for
>> bidirectional editing as a good example -- don't you need me to first teach
>> you enough about that, so you could make up your own mind, instead of just
>> trusting me? And if you are afraid of "issues" between us (i.e. you don't
>> really trust me 100%), why would you believe that I'll make an unbiased
>> presentation of what you need to learn, rather than bias it a bit to ensure
>> that you agree with me?
> I'm not sure it's worth derailing this thread to argue these things. Let them
> find some new maintainer(s), and those candidates can work out with the FSF
> whatever arrangement they prefer.
>
> John
>
>

Hi Eli,

doubt if there is anyone now knowing all the basic code which runs Emacs.

OTOH maintainership --while requiring technical knowledge-- basically is 
decision making, ruling out at cases presented by the parties.

The ability to preserve some coolness even in heated debates seems much 
more important than technical knowledge in detail.

Cheers,

Andreas

Re: New maintainer

[Eli Zaretskii]

> Date: Sun, 04 Oct 2015 10:18:04 +0200
> From: Andreas Röhler <andreas.roehler@online.de>
> CC: Eli Zaretskii <eliz@gnu.org>, John Wiegley <johnw@newartisans.com>
> 
> doubt if there is anyone now knowing all the basic code which runs Emacs.
> 
> OTOH maintainership --while requiring technical knowledge-- basically is 
> decision making, ruling out at cases presented by the parties.
> 
> The ability to preserve some coolness even in heated debates seems much 
> more important than technical knowledge in detail.

All true and agreed, but _some_ minimally useful degree of technical
knowledge is required for the decision making.  How can the head
maintainer make such decisions where he/she lacks that?

And even if he/she does have the minimal knowledge, can't it be that
it's not enough to make correct decisions in cases where the correct
alternative is not clear-cut, and the decision needs some intuition
(which is impossible without good knowledge and experience)?

Re: New maintainer

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > All true and agreed, but _some_ minimally useful degree of technical
  > knowledge is required for the decision making.

We can't expect the impossible.  A perfect Emacs maintainer would be
familiar with all the code in Emacs.  We won't find a person like
that, but Stefan has shown that a less-than-perfect maintainer can do
a good job.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: New maintainer

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: andreas.roehler@online.de, johnw@newartisans.com,
> 	emacs-devel@gnu.org
> Date: Mon, 05 Oct 2015 13:05:48 -0400
> 
>   > All true and agreed, but _some_ minimally useful degree of technical
>   > knowledge is required for the decision making.
> 
> We can't expect the impossible.  A perfect Emacs maintainer would be
> familiar with all the code in Emacs.  We won't find a person like
> that, but Stefan has shown that a less-than-perfect maintainer can do
> a good job.

No disagreement here, neither in principle nor wrt Stefan's work.

The issue is merely how to organize the maintainership, and how to
define the division of responsibilities with c-maintainers, if there
will be such.

Re: New maintainer

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> The issue is merely how to organize the maintainership, and how to define
> the division of responsibilities with c-maintainers, if there will be such.

This is a great question, and one I've been pondering myself, since the most
pressing variable for me in all of this is time.

Where I think I can contribute best is the bigger picture, or "meta issues":
weighing in on technical discussions, making higher-level decisions about
technical direction, keeping an eye on user experience within the community
and the quality of Emacs resources, coordinating volunteers, ensuring proper
legal forms are maintained, liaising with the FSF, and assisting other
maintainers so they don't burnout and receive the help they need.

What I probably don't have enough time for is giving all the issues, code
submissions, and discussions on emacs-devel, the depth and refinement they
deserve. This is where I've noticed Eli (and certainly Stefan) doing an
excellent job. I'm quite impressed by their energy and involvement. I would
need such people to make this job even possible within the constraints of my
life.

I also think that detail-level maintenance is far more likely to induce
burnout, since the flood at that level can be intense. Seeing the number of
replies by Eli and Stefan in the past few weeks has been impressive to say the
least, and requires a special kind of interest and energy to maintain. How do
we best support them? How do we find more hands to make lighter work for our
stalwart contributors?

Meanwhile, I want to think about the road leading to Emacs 26, and to work
with Eli, and the community as a whole, on what makes the most sense in terms
of what we have now, and what we want Emacs to become. For example, we have
compute-intensive applications -- such as Gnus -- that cannot take advantage
of the additional power offered by multi-core CPUs. How do we add concurrency
without increasing our maintenance burden due to impossible-to-reproduce bugs,
race conditions, and terrible error messages (a Backtrace, but from which
thread?). It will require significant collaboration to decide exactly what we
want, and what Emacs needs, from such features.

Another area we're falling behind in is the type of IDE features that are
taken for granted in special-purpose editing environments, such as effortless
code browsing, refactoring, and more interactive debugging. The things you can
do when editing Java and Javascript are downright impressive, and I see no
reason Emacs can't compete better here.

It would be hard to care about these issues in sufficient depth if the job of
project maintenance also required keeping an eye on every issue and technical
discussion. I think having co-maintainers (maybe several) who are good at
detail is absolutely essential to getting this job done.

John

Re: New maintainer

[Eli Zaretskii]

> From: John Wiegley <johnw@newartisans.com>
> Date: Mon, 05 Oct 2015 12:02:50 -0700
> 
> we have compute-intensive applications -- such as Gnus -- that
> cannot take advantage of the additional power offered by multi-core
> CPUs. How do we add concurrency without increasing our maintenance
> burden due to impossible-to-reproduce bugs, race conditions, and
> terrible error messages (a Backtrace, but from which thread?).

There's the concurrency branch in the repository.  It needs to be
revived (didn't see any activity for the last 2 years), and was not
really ready for prime time last time I looked at it (see
http://lists.gnu.org/archive/html/emacs-devel/2013-08/msg00704.html
and its continuation into Sep 2013).  But it's not far from its
proclaimed goal.

Re: New maintainer

[Daniel Colascione]

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

On 10/05/2015 12:32 PM, Eli Zaretskii wrote:
>> From: John Wiegley <johnw@newartisans.com>
>> Date: Mon, 05 Oct 2015 12:02:50 -0700
>>
>> we have compute-intensive applications -- such as Gnus -- that
>> cannot take advantage of the additional power offered by multi-core
>> CPUs. How do we add concurrency without increasing our maintenance
>> burden due to impossible-to-reproduce bugs, race conditions, and
>> terrible error messages (a Backtrace, but from which thread?).
> 
> There's the concurrency branch in the repository.  It needs to be
> revived (didn't see any activity for the last 2 years), and was not
> really ready for prime time last time I looked at it (see
> http://lists.gnu.org/archive/html/emacs-devel/2013-08/msg00704.html
> and its continuation into Sep 2013).  But it's not far from its
> proclaimed goal.

It isn't, but I'm still not sure that goal is the right one. I much
prefer a world where we don't have shared mutable state: the web workers
model from the web is a good one, and like any concurrency solution for
Emacs, it addresses the problem of integrating multiprocessing into a
legacy single-threaded environment.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: New maintainer

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Daniel Colascione <dancol@dancol.org>
> Date: Mon, 5 Oct 2015 12:38:18 -0700
> 
> > There's the concurrency branch in the repository.  It needs to be
> > revived (didn't see any activity for the last 2 years), and was not
> > really ready for prime time last time I looked at it (see
> > http://lists.gnu.org/archive/html/emacs-devel/2013-08/msg00704.html
> > and its continuation into Sep 2013).  But it's not far from its
> > proclaimed goal.
> 
> It isn't, but I'm still not sure that goal is the right one. I much
> prefer a world where we don't have shared mutable state: the web workers
> model from the web is a good one, and like any concurrency solution for
> Emacs, it addresses the problem of integrating multiprocessing into a
> legacy single-threaded environment.

Maybe you are right, but IMO it would be silly for us not to try that
branch first, through which we will gain firsthand experience and
knowledge of what kind of concurrency we need.

Otherwise, it will be another idea that ended in just talking.

Re: New maintainer

[Eli Zaretskii]

> From: John Wiegley <johnw@newartisans.com>
> Date: Mon, 05 Oct 2015 12:02:50 -0700
> 
> I also think that detail-level maintenance is far more likely to induce
> burnout, since the flood at that level can be intense. Seeing the number of
> replies by Eli and Stefan in the past few weeks has been impressive to say the
> least, and requires a special kind of interest and energy to
> maintain.

Your observations regarding my responses are most probably biased due
to a public holiday we had here for the last 3 weeks.  That ends
tonight.

In general, I have much less time to work on Emacs than Stefan and
many others here.

> How do we best support them? How do we find more hands to make
> lighter work for our stalwart contributors?

Excellent questions.

Re: New maintainer

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> Your observations regarding my responses are most probably biased due to a
> public holiday we had here for the last 3 weeks. That ends tonight.

In that case, thank you for spending so much of your holiday attending to
Emacs! It is much appreciated. :)

John

Re: New maintainer

[Dmitry Gutov]

On 10/05/2015 10:02 PM, John Wiegley wrote:

> This is a great question, and one I've been pondering myself, since the most
> pressing variable for me in all of this is time.

I fear that might be a problem.

> Where I think I can contribute best is the bigger picture, or "meta issues":
> weighing in on technical discussions, making higher-level decisions about
> technical direction, keeping an eye on user experience within the community

In the end, you might encounter a lack of clearly defined points when 
someone asks you to make a decision.

More often, the regular contributors already have an idea what they want 
to do in the limited time they can spend working on Emacs, and often 
it's not easy to make such a person change their mind.

Not every change is announced or discussed either, so I think a 
maintainer should be subscribed to emacs-diffs.

Likewise, even if you make a decision that a certain aspect of Emacs 
needs work, there's no guarantee that someone else will readily begin 
working on it.

> and the quality of Emacs resources, coordinating volunteers, ensuring proper
> legal forms are maintained, liaising with the FSF, and assisting other
> maintainers so they don't burnout and receive the help they need.

We really don't have enough volunteers. So an ideal maintainer, IMHO, 
would find ways to energize more people to volunteer, maybe by making 
the contribution process easier somehow (one could mention a better bug 
tracker, code review process, CI, documentation, etc; in short, a lot of 
things could be better, and all of them require work, in the end, rather 
than simply discussions and decisions), making the development process 
more transparent to the community, or, you know, handling a lot of the 
grunt work themselves. Maybe all of the options together.

> Another area we're falling behind in is the type of IDE features that are
> taken for granted in special-purpose editing environments, such as effortless
> code browsing, refactoring, and more interactive debugging. The things you can
> do when editing Java and Javascript are downright impressive, and I see no
> reason Emacs can't compete better here.

That area is closer to my interests, and I'd happily see one more person 
(or several) participate in these discussions, but preferably in 
lower-level terms (like the details of the xref interface, or the 
project API). So far, they've ended more in disagreement than anything 
else, and it's pretty discouraging.

Re: New maintainer

[Artur Malabarba]

2015-10-05 22:20 GMT+01:00 Dmitry Gutov <dgutov@yandex.ru>:
>> and the quality of Emacs resources, coordinating volunteers, ensuring
>> proper
>> legal forms are maintained, liaising with the FSF, and assisting other
>> maintainers so they don't burnout and receive the help they need.
>
>
> We really don't have enough volunteers. So an ideal maintainer, IMHO, would
> find ways to energize more people to volunteer, maybe by making the
> contribution process easier somehow (one could mention a better bug tracker,
> code review process, CI, documentation, etc; in short, a lot of things could
> be better, and all of them require work, in the end, rather than simply
> discussions and decisions), making the development process more transparent
> to the community, or, you know, handling a lot of the grunt work themselves.
> Maybe all of the options together.

Also just invite more devs with Melpa packages to contribute their
packages to GNU Elpa.
This gives them a good motivation to take care of all the paperwork
and get sorted with a savannah account, at which point they have a
decent chance of starting to contribute more packages or helping out
with emacs.git directly.

I suspect there are many package authors out there who are potential
regular/semi-regular contributors, but they're unlikely to just come
and ask for permission for a number of reasons.
That was my entry-drug (thanks Stefan) and I'm sure it would work on a
few others.

Re: New maintainer

[John Wiegley]

>>>>> Artur Malabarba <bruce.connor.am@gmail.com> writes:

> I suspect there are many package authors out there who are potential
> regular/semi-regular contributors, but they're unlikely to just come and ask
> for permission for a number of reasons. That was my entry-drug (thanks
> Stefan) and I'm sure it would work on a few others.

I think you're exactly right, Artur. I bet if asked, a lot of potential
contributors would say, "Who, me?" They simply haven't considered themselves
in that role yet.

John

Re: New maintainer

[Artur Malabarba]

I'll try to provide some help with GNU Elpa (reading diffs, helping
new devs, inviting people). Sadly, my time is (and will continue to
be) very sporadic so I can't offer to be The Maintainer for elpa.git.


2015-10-05 23:24 GMT+01:00 John Wiegley <johnw@newartisans.com>:
>>>>>> Artur Malabarba <bruce.connor.am@gmail.com> writes:
>
>> I suspect there are many package authors out there who are potential
>> regular/semi-regular contributors, but they're unlikely to just come and ask
>> for permission for a number of reasons. That was my entry-drug (thanks
>> Stefan) and I'm sure it would work on a few others.
>
> I think you're exactly right, Artur. I bet if asked, a lot of potential
> contributors would say, "Who, me?" They simply haven't considered themselves
> in that role yet.
>
> John
>

Re: New maintainer

[John Wiegley]

>>>>> Artur Malabarba <bruce.connor.am@gmail.com> writes:

> I'll try to provide some help with GNU Elpa (reading diffs, helping new
> devs, inviting people). Sadly, my time is (and will continue to be) very
> sporadic so I can't offer to be The Maintainer for elpa.git.

Whatever help you could offer would be most appreciated, Artur. At the very
least you'll have trodden the ground, so you can help other potential
contributors get up to speed faster.

John

Re: New maintainer

[Andreas Röhler]

Am 05.10.2015 um 23:20 schrieb Dmitry Gutov:
> [ ... ]
> We really don't have enough volunteers. 

[ ... ]

Might the FSF copyright assigment policy being a major cause here?

Re: New maintainer

[Ricardo Wurmus]

Andreas Röhler <andreas.roehler@online.de> writes:

> Am 05.10.2015 um 23:20 schrieb Dmitry Gutov:
>> [ ... ]
>> We really don't have enough volunteers. 
>
> [ ... ]
>
> Might the FSF copyright assigment policy being a major cause here?

For me the copyright assigment policy hasn’t been an obstacle to
contribution in another GNU project.  What keeps me from contributing to
Emacs is just this peculiar mix of not knowing enough details and time
spent on other projects.

I found a list of simple tasks that new contributors could tackle in
another project (the Hurd) very encouraging, leaving only time
management as a reason not to contribute.

Copyright assignment is a one-time thing and it doesn’t take much time.

~~ Ricardo

Re: New maintainer

[David Kastrup]

Andreas Röhler <andreas.roehler@online.de> writes:

> Am 05.10.2015 um 23:20 schrieb Dmitry Gutov:
>> [ ... ]
>> We really don't have enough volunteers. 
>
> [ ... ]
>
> Might the FSF copyright assigment policy being a major cause here?

XEmacs doesn't have it and does not really fare better in that regard.
Elisp is more likely to be a contributing factor.  Either are not going
to go away, but there have been some improvements regarding how
burdensome either turn out in practice.

-- 
David Kastrup

Re: New maintainer

[Andreas Röhler]

Am 05.10.2015 um 23:20 schrieb Dmitry Gutov:
> On 10/05/2015 10:02 PM, John Wiegley wrote:
>
[ ... ]
>> Another area we're falling behind in is the type of IDE features that 
>> are
>> taken for granted in special-purpose editing environments, such as 
>> effortless
>> code browsing, refactoring, and more interactive debugging. The 
>> things you can
>> do when editing Java and Javascript are downright impressive, and I 
>> see no
>> reason Emacs can't compete better here.
>
> That area is closer to my interests, and I'd happily see one more 
> person (or several) participate in these discussions, but preferably 
> in lower-level terms (like the details of the xref interface, or the 
> project API). So far, they've ended more in disagreement than anything 
> else, and it's pretty discouraging.
>
>

IMO rather third party libraries should be encouraged.

For example WRT Python we have already several:

the python-mode.el/pymacs/rope eco-system
emacs-for-python,
and elpy, relying on shipped python.el  and jedi/rope

AFAICS Emacs provides all to built IDEs upon. OTOH doing it requires 
special knowledge in the languages, which can't be expected from 
core-developers.

Exists related efforts at other languages.

Emacs core-developers could have a stronger role by advising them.
Strengthening communication in community seems the way to go WRT IDEs.

Re: New maintainer

[Rasmus]

Andreas Röhler <andreas.roehler@online.de> writes:

> IMO rather third party libraries should be encouraged.

"Batteries included", especially for those of us who have do some work on
company issued PCs.  Though ELPA is making this less of a concern.

Rasmus

-- 
It was you, Jezebel, it was you

Re: New maintainer

[Paul Nathan]

On Mon, Oct 5, 2015 at 12:02 PM, John Wiegley <johnw@newartisans.com> wrote:
>

[snip]

> Another area we're falling behind in is the type of IDE features that are
> taken for granted in special-purpose editing environments, such as effortless
> code browsing, refactoring, and more interactive debugging. The things you can
> do when editing Java and Javascript are downright impressive, and I see no
> reason Emacs can't compete better here.
>

[snip]

>
> John
>


Hi,

As a daily Emacs user, I would like to submit that the above snippet
is keenly important.  I would urge maintainers to run Visual Studio
(C#) and IntelliJ(Java) and experiment with their capabilities....
then beat them in Emacs.

Using SLIME and the Rust completion user interfaces is still a subpar
UI experience compared to IntelliJ or VS.


I would hope that the maintainer would accept the task of beating
proprietary software capabilities head to head (not a simple task!),
instead of simply being excellent. :-)

Re: New maintainer

[Dmitry Gutov]

On 10/06/2015 04:15 AM, Paul Nathan wrote:

> Using SLIME and the Rust completion user interfaces is still a subpar
> UI experience compared to IntelliJ or VS.

You might want to clarify that statement in more detail. Creating a bug 
report would be best.

> I would hope that the maintainer would accept the task of beating
> proprietary software capabilities head to head (not a simple task!),
> instead of simply being excellent. :-)

Personally, I wouldn't want to have exactly the same interface, but 
foremost add features that give the most benefit over cost of 
implementation.

So, what are your primary pet peeves about using Racer [0]?

[0] https://github.com/racer-rust/emacs-racer

Re: New maintainer

[Andreas Röhler]

Am 06.10.2015 um 06:30 schrieb Dmitry Gutov:
> On 10/06/2015 04:15 AM, Paul Nathan wrote:
>
>> Using SLIME and the Rust completion user interfaces is still a subpar
>> UI experience compared to IntelliJ or VS.
>
> You might want to clarify that statement in more detail. Creating a 
> bug report would be best.

Decisions where to head into these area train considerable investments.
Complex questions can't be rolled into a simple bug-report. Also it 
surpasses a feature request.

If Emacs wants to keep path in nowadays evolving world, it needs to 
adapt its discussion-format.

Re: New maintainer

[Rasmus]

Andreas Röhler <andreas.roehler@online.de> writes:

> Am 06.10.2015 um 06:30 schrieb Dmitry Gutov:
>> On 10/06/2015 04:15 AM, Paul Nathan wrote:
>>
>>> Using SLIME and the Rust completion user interfaces is still a subpar
>>> UI experience compared to IntelliJ or VS.
>>
>> You might want to clarify that statement in more detail. Creating a
>> bug report would be best.
>
> Decisions where to head into these area train considerable investments.
> Complex questions can't be rolled into a simple bug-report. Also it
> surpasses a feature request.

Andreas, with all respect, this statement is untrue.  We are talking
software here, not rocked science.  The reason it is better can be broken
down into a set of independent functionalities, that makes it betterᵀᴹ.
For each feature in this set you can make a bug request.  In order to make
any progress, you've got to break down the problem into its parts.

Rasmus

-- 
Dung makes an excellent fertilizer

Re: New maintainer

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I am very backlogged on email this week.

  > As a daily Emacs user, I would like to submit that the above snippet
  > is keenly important.  I would urge maintainers to run Visual Studio
  > (C#) and IntelliJ(Java) and experiment with their capabilities....
  > then beat them in Emacs.

I want the GNU system to have this functionality.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: New maintainer

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I think it's up to the people in the new maintainer team
to decide how to work together.  There is no rule that says they
have to formalize it.  Whatever works for them, is good.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: New maintainer

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

You're right that three people can't deadlock -- but I hope that the
people in a group of maintainers will reach consensus through
persuasion, rather than deciding by voting.  Stefan and Yidong were
able to reach decisions together, and did not need to do it by voting.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: New maintainer

[Bastien]

Hello,

"John Wiegley" <johnw@newartisans.com> writes:

>>>>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> So, now that I stepped down, we need to find a new maintainer (or a new
>> maintainer-team).
>
> I'd like to self-nominate for that role, Stefan.

I strongly support John as a possible new maintainer for Emacs,
possibly in a team with Eli, which I strongly support too.

I maintain Org-mode since 2011 (with a lower activity in 2015 but
more time in 2016).  Along those years, interacting with John has
always been both helpful and enjoyable.

I completely trust John for moving Emacs forward into the right
direction, and for supporting GNU's goal as a whole.

Having discussions on what are the best ways to achieve freedom
through softwares is both natural and important: varying points
of view keep us vigilant on what freedom is in general, and for
software users in particular.  This is something I value very
much, as long as it does not affect our collectively assumed
goals, which are, right now, the goals of the GNU project.

-- 
 Bastien

Re: New maintainer

[Travis Jeffery]

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

On Tue, Sep 29, 2015 at 5:46 PM, John Wiegley <johnw@newartisans.com> wrote:

> >>>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> > So, now that I stepped down, we need to find a new maintainer (or a new
> > maintainer-team).
>
> I'd like to self-nominate for that role, Stefan.
>

John would be an excellent maintainer (or co/head maintainer), in my
opinion.

- Travis

On Tue, Sep 29, 2015 at 5:46 PM, John Wiegley <johnw@newartisans.com> wrote:

> >>>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> > So, now that I stepped down, we need to find a new maintainer (or a new
> > maintainer-team).
>
> I'd like to self-nominate for that role, Stefan. I've been contributing to
> Emacs since 1994, and have loved it all the while. Emacs Lisp remains a
> very
> enjoyable language to write certain types of code in.
>
> Some things I'd like to see happen to Emacs are more efficiency, closing
> bugs,
> and wider adoption of some of our newest features, like lexical scoping.
> That
> said, I'm also excited by new prospects, and wonder what can be done in the
> area of concurrency (in some form), a new language under the hood (Guile?),
> etc.
>
> Emacs is my favorite application, by far, and the one I spend the most time
> in, both professionally and personally. It's my programming environment,
> E-mail reader, IRC client, task manager, note taker, and occasional shell.
> I'm
> hoping it will still be the best choice for these things after twenty
> _more_
> years of use, and perhaps as head maintainer I could help keep things
> moving
> in that direction.
>
> John
>
>

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

Re: New maintainer

[Xue Fuqiao]

On Tue, Sep 29, 2015 at 2:28 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:

> But we still need a head maintainer, whose task is mostly to keep an eye
> on the general direction, can make a final decision when we can't reach
> an agreement (of course, we could also delegate that task to
> /dev/random), and to be the official contact point with the FSF.

Agreed.  In old-timers, I'd recommend Glenn Morris, Eli Zaretskii, Paul
Eggert, Lars Magne Ingebrigtsen, and Martin Rudalics.  In the "new
blood", I'd recommend Dmitry Gutov and Artur Malabarba.  Just my 2 cents.

(Although I'm also interested in maintaining Emacs, and I shall have
some spare time to devote to this, I'm not sure if I'm qualified for the
work.)