all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Review a blog post about emacs-devel
@ 2020-04-27 20:58 Yuan Fu
  2020-04-27 21:31 ` Noam Postavsky
                   ` (3 more replies)
  0 siblings, 4 replies; 22+ messages in thread
From: Yuan Fu @ 2020-04-27 20:58 UTC (permalink / raw)
  To: Emacs developers

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

I wrote a blog post about how to participate in emacs-devel in the hope that this will help with people who wants to contribute. Before I publish it, could some one have a look at it to see if there is misinformation?  Any advice/concern is welcome. Thanks.

Yuan


[-- Attachment #2: index.org --]
[-- Type: application/octet-stream, Size: 11844 bytes --]

#+SETUPFILE: ../../setup.org
#+TITLE: Contributing to Emacs
#+DATE: <2020-04-25 Sat 16:59>
#+TAGS: Emacs Hacker
#+OPTIONS: toc:1

Emacs, /the/ editor we all use and love, has been running for decades, receiving contribution from hundreds of hackers along the way. But because it predates “modern” open source workflows (a.k.a GitHub and friends) by many years, you can’t do the usual thing—open issues, fork and make PR’s, etc. However, while admittedly not as convenient as GitHub, Emacs’s development workflow isn’t as tedious and difficult as many people imagines (in particular, you don’t need Gnus or deal with email in Emacs, or setup anything fancy). In this post I show what I’ve learned as a Emacs new comer about participating the development of Emacs. I hope that by sharing people what does contributing to Emacs look like, more people knows what to expect and feels comfortable to join the development of Emacs.

* Report Emacs bug

I won’t go into details here, because I think most people nowadays are well educated by numerous open source projects on how to properly report a bug. In the case of Emacs, in addition, you want to reproduce the bug with vanilla Emacs, i.e., without your configurations. You can start one with =emacs -Q=. And in Emacs type =M-x report-emacs-bug RET=, then =C-x M-i= to use your mail application to send the bug report through email (Emacs instructs you of all this). Then just wait for a developer to reply your email (see? No setup needed). The only thing to remember is to make sure you use “reply all” when replying emails (more on that in [[The mailing list]].)

* The mailing list

GitHub has issues, we have the mailing list. A mailing list has subscribers. When some one sends a mail to (or cc) the mailing list address, the mailing list server forwards that message to every subscribers, so every body sees your mail. To start a new thread, send a mail to the mailing list server; to reply to someone’s message, simply “reply all”. *Make sure you use “reply all” when replying to messages.* If the message isn’t CC’ed to the mailing list server (emacs-devel@gnu.org), other people on the list can’t see it.

** Subscribe to Emacs-devel mailing list

Go to [[https://lists.gnu.org/mailman/listinfo/emacs-devel][Emacs-devel Info Page]], and fill in the form to subscribe. Make sure you select “No” for “Would you like to receive list mail batched in a daily digest?”. If you select “Yes”, instead of receiving messages, you receive a “daily digest” everyday, which is more or less useless becase 1) you don’t see the full conversation, 2) you can’t participate the discussion.

** Tips

Emacs-devel is busy, there are a couple dozen messages everyday, if you don’t want your inbox flooded, you better setup a separate mail folder for them. As an example, this is what I do on Gmail: I go to “Settings”, “Filters and Blocked Addresses”, “Create a new filter”, filter any mail that has the words “emacs-devel@gnu.org”, and asks Gmail to skip the inbox and apply “emacs-devel” label. The effect is that all emacs-devel messages don’t appear in your inbox and instead show up in emacs-devel folder.

** No one replies?

In general, give it a week or so before pinging your message. Normally when no one reply to a new message, it is because people have seen it don’t know enough to say anything intelligent about the topic. On the other hand, don’t send a bug report without a patch to emacs-devel, report it as a bug (even if you are not sure if it should be classified as a bug, report it as a bug).

* Get Emacs’ source

- This is Emacs’ savannah homepage: [[https://savannah.gnu.org/projects/emacs/]]
- This is Emacs’ git source page: http://git.savannah.gnu.org/cgit/emacs.git

The home page tells you how to clone Emacs’ source:
#+begin_src shell
git clone -b master git://git.sv.gnu.org/emacs.git
#+end_src

Once you have the source, you can find most of the information mentioned in this post in =/CONTRIBUTE=. For example, the first section clearly demonstrates how to compile Emacs:
#+begin_src shell
# More info is in INSTALL.
./autogen.sh
# You can use ./configure.sh --help to see the avaliable options.
# This is the step where you enable/disable optional functionalities
# like dynamic module, portable dumper, svg, etc.
./configure.sh
make
#+end_src

And the executable is =/src/emacs=, welcome to the future (release)! 
# --enable-checking=yes --enable-check-lisp-object-type=yes

* I have some code, what now?
** The copyright assignment

Every non-trivial contribution to GNU Emacs needs to have a copyright assignment signed. Basically by signing the assignment, you give the copyright of your code to FSF. See more at [[https://www.gnu.org/licenses/why-assign.en.html][Why Copyright Assignment]]. You need to first check with your employer before signing it. Most of the time it’s no problem. To sign the assignment, ask for a form on the mailing list, and someone will send you the form. You fill it in and send to the instructed “FSF clerk”, then he sends you the document to sign, either by email or by mail. You sign it and send it back, and he sends you the final document with FSF signature. 

** Conventions in code

- Write regular sentences in comment, i.e., with capitalization and period. Format comments with =M-q= (~fill-paragraph~).
- Comments should be in American English and with two spaces after every sentence.
- Don’t write over 80–90 columns (I don’t really know if there is a hard limit, but in general try to keep in with the rest of the code).

** Conventions in commit messages

The general format:
# I added zero width space before each star to prevent Org from considering them as headings
#+begin_example
Summary line (no ending period)

Some more info (optional).

​* file: Change.
​* file (variable1): Change.
​* file (function1, function2, variable3): Same change.
​* file (variable1): Change 1.
(function2): Change 2.
(function1, macro2): Same change.
#+end_example

- The file path is relative to the source root, e.g., =/lisp/progmodes/gdb-mi.el=.
- In =Change=, document /what/ changed, not /why/ the change is made. /“Why”/ is better put in the comments.
- For new function​/​variable​/​macro, It suffice to say “New function​/​variable​/​macro”.
- Don’t exceed 78 characters each line.
- Try to use only ASCII characters (so people on limited terminals can view these messages). For example, prefer straight quotes over curly quotes.
- Sames as comments—American English and two spaces after every sentence.

** Create patch and send it

Create a single patch for each individual changes. Don’t send a patch with three new features combined, that is harder to review; on the other hand, don’t send a series of patches for a single feature, squash[fn:1] them into one patch. Also, send your patch early and small and update along the way, that also helps other people to review it. To save you from googling, here’s some ways to create a patch:

1. Use magit. To generate a quick diff patch, open a diff buffer by either =d d= on a change or commit; in the diff buffer, hit =W s=. To generate a patch from a commit or a range of commits, go on to a commit and do =W c c=. This puts the patch file(s) under the project root and isn’t very convenient, I usually just do =! ! git format-patch -<# of commits> --stdout > <file>.=
2. From command line, =git format-patch -<# of commits, e.g., 1> --stdout > <file>=

To send your patch, write an email to the mailing list: [[mailto:emacs-devel@gnu.org][emacs-devel]]. Drag your patch to the very end of the message, after signatures. Normally this is all it needs. Sometimes the message could be garbled; in that case, changing the message to plain text usually helps. You can also send a patch to debbugs, the bug tracker, if the patch is a bug fix. (See [[Debbugs]].)

* NEWS and manual

If you made a user-visible change, you should document this change in the NEWS file, possibly also update the manual. *You don’t need to worry about these until your patch is finalized, though. So maybe skip this section for now.* And Emacs maintainers will let you know what to do. Below is the relevant section in =/CONTRIBUTE=:

#+begin_quote
Any change that matters to end-users should have an entry in etc/NEWS.
Try to start each NEWS entry with a sentence that summarizes the entry
and takes just one line -- this will allow to read NEWS in Outline
mode after hiding the body of each entry.

Doc-strings should be updated together with the code.

New defcustom's should always have a ':version' tag stating the first
Emacs version in which they will appear.  Likewise with defcustom's
whose value is changed -- update their ':version' tag.

Think about whether your change requires updating the manuals.  If you
know it does not, mark the NEWS entry with "---".  If you know
that *all* the necessary documentation updates have been made as part
of your changes or those by others, mark the entry with "+++".
Otherwise do not mark it.

If your change requires updating the manuals to document new
functions/commands/variables/faces, then use the proper Texinfo
command to index them; for instance, use @vindex for variables and
@findex for functions/commands.  For the full list of predefined indices, see
https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Predefined-Indices.html
or run the shell command 'info "(texinfo)Predefined Indices"'.
#+end_quote

* Debbugs

[[https://debbugs.gnu.org][Debbugs]] is the bug tracker for GNU operating system. Here is [[https://debbugs.gnu.org/Emacs.html][Emacs’ debbugs home page]]. I’ve covered how to report a bug. After you sent the email reporting the bug, debbugs will reply to you a confirmation email with a bug number. Instead of replying to messages in the bug report, you can also comment by sending a message to =bug-number@gnu.debbugs.org=. When the bug is fixed, you can send a message to =<bug-number>-done@debbugs.gnu.org=, e.g., =40000-done@debbugs.gnu.org=. That closes the bug.

If you want to view currently open bugs, you can either [[https://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs;max-bugs=100;base-order=1;bug-rev=1][browse online]], or view them in Emacs: install the package =debbugs= and =M-x debbugs-gnu=. You can click on bugs to view them, and view the conversation. You can even reply by =S w= on a message, and write your message in Emacs, and hit =C-c C-c= to send. Chose “mail client” and Emacs invokes your default mail application to send this mail. Hit =C-c C-k= to cancel the message.

* GNU ELPA

Have a good package? Add it to GNU ELPA! Pros:
- Get reviews from people that knows Emacs and Emacs Lisp best. 
- Instantly avaliable from vanilla Emacs. 
- You /can/ host your package on other places, such as GitHub.
- You /can/ push to your package without review, and don’t need to follow Emacs conventions for commit messages.
Cons:
- You need to sign the copyright assignment. And make sure all the contributors of your package (with significant contribution, i.e., ~15 lines) signs it.

View [[http://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/README][README]] for more detailed info.

[fn:1] Squash means combining several commits into one. It is easy to do with Magit: =l l= go to the log buffer; then go to the earliest commit you want to change, hit =r i=; hit =s= on the commits you wan to squash, commits marked with “s” will squash up. You can also use =M-n/p= to move the order of commits; then hit =C-c C-c= to edit the new commit message, and =C-c C-c= again to confirm.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Review a blog post about emacs-devel
  2020-04-27 20:58 Review a blog post about emacs-devel Yuan Fu
@ 2020-04-27 21:31 ` Noam Postavsky
  2020-04-27 21:37   ` Yuan Fu
  2020-04-29  6:33 ` Colin Baxter
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 22+ messages in thread
From: Noam Postavsky @ 2020-04-27 21:31 UTC (permalink / raw)
  To: Yuan Fu; +Cc: Emacs developers

On Mon, 27 Apr 2020 at 16:58, Yuan Fu <casouri@gmail.com> wrote:
>
> I wrote a blog post about how to participate in emacs-devel in the hope that this will help with people who wants to contribute. Before I publish it, could some one have a look at it to see if there is misinformation?  Any advice/concern is welcome. Thanks.

> On the other hand, don’t send a bug report without a patch to
> emacs-devel, report it as a bug (even if you are not sure if it should
> be classified as a bug, report it as a bug).

You can (and generally should) send bug reports/feature requests even
with patches to the bug list.



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Review a blog post about emacs-devel
  2020-04-27 21:31 ` Noam Postavsky
@ 2020-04-27 21:37   ` Yuan Fu
  0 siblings, 0 replies; 22+ messages in thread
From: Yuan Fu @ 2020-04-27 21:37 UTC (permalink / raw)
  To: Noam Postavsky; +Cc: Emacs developers



> On Apr 27, 2020, at 5:31 PM, Noam Postavsky <npostavs@gmail.com> wrote:
> 
> On Mon, 27 Apr 2020 at 16:58, Yuan Fu <casouri@gmail.com> wrote:
>> 
>> I wrote a blog post about how to participate in emacs-devel in the hope that this will help with people who wants to contribute. Before I publish it, could some one have a look at it to see if there is misinformation?  Any advice/concern is welcome. Thanks.
> 
>> On the other hand, don’t send a bug report without a patch to
>> emacs-devel, report it as a bug (even if you are not sure if it should
>> be classified as a bug, report it as a bug).
> 
> You can (and generally should) send bug reports/feature requests even
> with patches to the bug list.

Thanks, I should add a section about sending bug reports with patches.

Yuan


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Review a blog post about emacs-devel
  2020-04-27 20:58 Review a blog post about emacs-devel Yuan Fu
  2020-04-27 21:31 ` Noam Postavsky
@ 2020-04-29  6:33 ` Colin Baxter
  2020-04-29  6:49 ` Jean-Christophe Helary
  2020-04-30  2:28 ` Richard Stallman
  3 siblings, 0 replies; 22+ messages in thread
From: Colin Baxter @ 2020-04-29  6:33 UTC (permalink / raw)
  To: Yuan Fu; +Cc: Emacs developers

>>>>> Yuan Fu <casouri@gmail.com> writes:

    > I wrote a blog post about how to participate in emacs-devel in the
    > hope that this will help with people who wants to
    > contribute. Before I publish it, could some one have a look at it
    > to see if there is misinformation?  Any advice/concern is
    > welcome. Thanks.

    > Yuan

On a style issue, Microsoft :-( has now declared the double-space after
a period (full-stop) to be an error:

https://it.slashdot.org/story/20/04/24/1411239/microsoft-word-now-flags-double-spaces-as-errors-ending-the-great-space-debate?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Slashdot%2Fslashdot+%28Slashdot%29

But that's Microsoft.

Best wishes,


-- 
Colin Baxter
URL: http://www.Colin-Baxter.com
---------------------------------------------------------------------
GnuPG fingerprint: 68A8 799C 0230 16E7 BF68  2A27 BBFA 2492 91F5 41C8
---------------------------------------------------------------------



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Review a blog post about emacs-devel
  2020-04-27 20:58 Review a blog post about emacs-devel Yuan Fu
  2020-04-27 21:31 ` Noam Postavsky
  2020-04-29  6:33 ` Colin Baxter
@ 2020-04-29  6:49 ` Jean-Christophe Helary
  2020-04-29 14:08   ` Yuan Fu
  2020-04-29 14:51   ` Drew Adams
  2020-04-30  2:28 ` Richard Stallman
  3 siblings, 2 replies; 22+ messages in thread
From: Jean-Christophe Helary @ 2020-04-29  6:49 UTC (permalink / raw)
  To: Emacs developers



> On Apr 28, 2020, at 5:58, Yuan Fu <casouri@gmail.com> wrote:
> 
> I wrote a blog post about how to participate in emacs-devel in the hope that this will help with people who wants to contribute. Before I publish it, could some one have a look at it to see if there is misinformation?  Any advice/concern is welcome. Thanks.

Can I suggest that you replace '"modern" open source workflows' with "recent ..."


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune





^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Review a blog post about emacs-devel
  2020-04-29  6:49 ` Jean-Christophe Helary
@ 2020-04-29 14:08   ` Yuan Fu
  2020-04-29 14:51   ` Drew Adams
  1 sibling, 0 replies; 22+ messages in thread
From: Yuan Fu @ 2020-04-29 14:08 UTC (permalink / raw)
  To: Jean-Christophe Helary; +Cc: Emacs developers

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

> 
> Can I suggest that you replace '"modern" open source workflows' with "recent ..."
> 
> 
> Jean-Christophe Helary
> -----------------------------------------------
> http://mac4translators.blogspot.com @brandelune
> 
> 
> 

Good call.

> On a style issue, Microsoft :-( has now declared the double-space after
> a period (full-stop) to be an error:
> 
> https://it.slashdot.org/story/20/04/24/1411239/microsoft-word-now-flags-double-spaces-as-errors-ending-the-great-space-debate?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Slashdot%2Fslashdot+%28Slashdot%29 <https://it.slashdot.org/story/20/04/24/1411239/microsoft-word-now-flags-double-spaces-as-errors-ending-the-great-space-debate?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Slashdot%2Fslashdot+%28Slashdot%29>
> 
> But that's Microsoft.
> 

From the typographical point of view, it is true that one shouldn’t use double spaces. However, I’m sure Emacs’ rule for double space comes with technical reasons (distinguishing sentences from abbreviations, etc). And I’m just recapitulating the manual.

Yuan




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

^ permalink raw reply	[flat|nested] 22+ messages in thread

* RE: Review a blog post about emacs-devel
  2020-04-29  6:49 ` Jean-Christophe Helary
  2020-04-29 14:08   ` Yuan Fu
@ 2020-04-29 14:51   ` Drew Adams
  2020-04-29 16:14     ` Yuan Fu
  1 sibling, 1 reply; 22+ messages in thread
From: Drew Adams @ 2020-04-29 14:51 UTC (permalink / raw)
  To: Jean-Christophe Helary, Emacs developers

> Can I suggest that you replace '"modern" open source workflows' with "recent ..."

+1.

But better yet, say what you really mean by 
that.  What particular features/qualities
define/describe that class?  No need to be
exhaustive, but some mention of _something_
would help.

There's nothing _inherently_ important or
interesting about a workflow being recent
or "modern".  What about those workflows
you have in mind is relevant here?



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Review a blog post about emacs-devel
  2020-04-29 14:51   ` Drew Adams
@ 2020-04-29 16:14     ` Yuan Fu
  0 siblings, 0 replies; 22+ messages in thread
From: Yuan Fu @ 2020-04-29 16:14 UTC (permalink / raw)
  To: Drew Adams; +Cc: Jean-Christophe Helary, Emacs developers



> On Apr 29, 2020, at 10:51 AM, Drew Adams <drew.adams@oracle.com> wrote:
> 
>> Can I suggest that you replace '"modern" open source workflows' with "recent ..."
> 
> +1.
> 
> But better yet, say what you really mean by 
> that.  What particular features/qualities
> define/describe that class?  No need to be
> exhaustive, but some mention of _something_
> would help.
> 
> There's nothing _inherently_ important or
> interesting about a workflow being recent
> or "modern".  What about those workflows
> you have in mind is relevant here?
> 

I mentioned GitHub and its issue and pull request feature. I figure that’s what most people are familiar with nowadays.

Yuan


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Review a blog post about emacs-devel
  2020-04-27 20:58 Review a blog post about emacs-devel Yuan Fu
                   ` (2 preceding siblings ...)
  2020-04-29  6:49 ` Jean-Christophe Helary
@ 2020-04-30  2:28 ` Richard Stallman
  2020-04-30 15:19   ` Yuan Fu
                     ` (2 more replies)
  3 siblings, 3 replies; 22+ messages in thread
From: Richard Stallman @ 2020-04-30  2:28 UTC (permalink / raw)
  To: Yuan Fu; +Cc: emacs-devel

[[[ 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. ]]]

Would you please talk about "free software" or "libre software", not
"open source"?

The free software movement campaigns for software to respect users'
freedom.  See https://gnu.org/philosophy/free-sw.html for the
explanation of the four essential freedoms.  The ides of the free
software movement is that denying a user these four freedoms is an
injustice, and that we aim to end that injustice.  See
https://gnu.org/philosophy/free-software-even-more-important.html.

In 1998, people who disagreed with the free software movement's
philosophy coined the term "open source" with the aim of causing the
free software movement to be hidden behind a dense cloud of "open
source" so that people would forget about our ideas.  Therefore, we
must give high proprity to showing people that we shand for free
software and _not_ for open source.  We never use the words "open
source", or even "open" as an adjective applied to software,
except to explain that it is NOT what we stand for.

See https://gnu.org/philosophy/open-source-misses-the-point.html
for more explanation.

Also, please don't use GitHub as a standard of comparison.  That would
promote GitHub, which is counter to what we aim to do.

Please don't promote Emacs Lisp packages that we don't have papers
to include in Emacs or GNU ELPA.  That includes Magit.

Jonas Bernoulli recently asked for access to the Emacs repo.  That
suggests that we have made progress on the needed papers and be able
incorporate Magit into Emacs soon.  Then we could document it here,
and in the Emacs manual.

But we must not count that chicken until it hatches.  Therefore, I
have commented out that text with #'s.  The idea is that it should not
appear in the document we publish, but we should not lose it because
we will want to include it in the future.

I do not know Org mode syntax, so I may have made errors in editing it.

Here is my edited draft.



#+SETUPFILE: ../../setup.org
#+TITLE: Contributing to Emacs
#+DATE: <2020-04-25 Sat 16:59>
#+TAGS: Emacs Hacker
#+OPTIONS: toc:1

Emacs, /the/ editor we all use and love, has been running for decades, receiving contribution from hundreds of hackers along the way. But because it predates “modern” libre software workflows by many years, you can’t do the usual thing—open issues, fork and make PR’s, etc. However, Emacs’s development workflow isn’t as tedious and difficult as many people imagines (in particular, you don’t need Gnus or deal with email in Emacs, or setup anything fancy). In this post I show what I’ve learned as a Emacs new comer about participating the development of Emacs. I hope that by sharing people what does contributing to Emacs look like, more people knows what to expect and feels comfortable to join the development of Emacs.

* Report Emacs bug

I won’t go into details here, because I think most people nowadays are well educated by numerous libre projects on how to properly report a bug. In the case of Emacs, in addition, you want to reproduce the bug with vanilla Emacs, i.e., without your configurations. You can start one with =emacs -Q=. And in Emacs type =M-x report-emacs-bug RET=, then =C-x M-i= to use your mail application to send the bug report through email (Emacs instructs you of all this). Then just wait for a developer to reply your email (see? No setup needed). The only thing to remember is to make sure you use “reply all” when replying emails (more on that in [[The mailing list]].)

* The mailing list

We keep track of pending bug reports using the mailing list. A mailing list has subscribers. When some one sends a mail to (or cc) the mailing list address, the mailing list server forwards that message to every subscribers, so every body sees your mail. To start a new thread, send a mail to the mailing list server; to reply to someone’s message, simply “reply all”. *Make sure you use “reply all” when replying to messages.* If the message isn’t CC’ed to the mailing list server (emacs-devel@gnu.org), other people on the list can’t see it.

** Subscribe to Emacs-devel mailing list

Go to [[https://lists.gnu.org/mailman/listinfo/emacs-devel][Emacs-devel Info Page]], and fill in the form to subscribe. Make sure you select “No” for “Would you like to receive list mail batched in a daily digest?”. If you select “Yes”, instead of receiving messages, you receive a “daily digest” everyday, which is more or less useless becase 1) you don’t see the full conversation, 2) you can’t participate the discussion.

** Tips

Emacs-devel is busy, there are a couple dozen messages everyday, if you don’t want your inbox flooded, you better setup a separate mail folder for them. As an example, this is what I do on Gmail: I go to “Settings”, “Filters and Blocked Addresses”, “Create a new filter”, filter any mail that has the words “emacs-devel@gnu.org”, and asks Gmail to skip the inbox and apply “emacs-devel” label. The effect is that all emacs-devel messages don’t appear in your inbox and instead show up in emacs-devel folder.

** No one replies?

In general, give it a week or so before pinging your message. Normally when no one reply to a new message, it is because people have seen it don’t know enough to say anything intelligent about the topic. On the other hand, don’t send a bug report without a patch to emacs-devel, report it as a bug (even if you are not sure if it should be classified as a bug, report it as a bug).

* Get Emacs’ source

- This is Emacs’ savannah homepage: [[https://savannah.gnu.org/projects/emacs/]]
- This is Emacs’ git source page: http://git.savannah.gnu.org/cgit/emacs.git

The home page tells you how to clone Emacs’ source:
#+begin_src shell
git clone -b master git://git.sv.gnu.org/emacs.git
#+end_src

Once you have the source, you can find most of the information mentioned in this post in =/CONTRIBUTE=. For example, the first section clearly demonstrates how to compile Emacs:
#+begin_src shell
# More info is in INSTALL.
./autogen.sh
# You can use ./configure.sh --help to see the avaliable options.
# This is the step where you enable/disable optional functionalities
# like dynamic module, portable dumper, svg, etc.
./configure.sh
make
#+end_src

And the executable is =/src/emacs=, welcome to the future (release)! 
# --enable-checking=yes --enable-check-lisp-object-type=yes

* I have some code, what now?
** The copyright assignment

Every non-trivial contribution to GNU Emacs needs to have a copyright assignment signed. Basically by signing the assignment, you give the copyright of your code to FSF. See more at [[https://www.gnu.org/licenses/why-assign.en.html][Why Copyright Assignment]]. You need to first check with your employer before signing it. Most of the time it’s no problem. To sign the assignment, ask for a form on the mailing list, and someone will send you the form. You fill it in and send to the instructed “FSF clerk”, then he sends you the document to sign, either by email or by mail. You sign it and send it back, and he sends you the final document with FSF signature. 

** Conventions in code

- Write regular sentences in comment, i.e., with capitalization and period. Format comments with =M-q= (~fill-paragraph~).
- Comments should be in American English and with two spaces after every sentence.
- Don’t make comment lines longer than 70 columns.

** Conventions in commit messages

The general format:
# I added zero width space before each star to prevent Org from considering them as headings
#+begin_example
Summary line (no ending period)

Some more info (optional).

​* file: Change.
​* file (variable1): Change.
​* file (function1, function2, variable3): Same change.
​* file (variable1): Change 1.
(function2): Change 2.
(function1, macro2): Same change.
#+end_example

- The file path is relative to the source root, e.g., =/lisp/progmodes/gdb-mi.el=.
- In =Change=, document /what/ changed, not /why/ the change is made. /“Why”/ is better put in the comments.
- For new function​/​variable​/​macro, It suffice to say “New function​/​variable​/​macro”.
- Don’t exceed 78 characters each line.
- Try to use only ASCII characters (so people on limited terminals can view these messages). For example, prefer straight quotes over curly quotes.
- Sames as comments—American English and two spaces after every sentence.

** Create patch and send it

Create a single patch for each individual changes. Don’t send a patch with three new features combined, that is harder to review; on the other hand, don’t send a series of patches for a single feature, squash[fn:1] them into one patch. Also, send your patch early and small and update along the way, that also helps other people to review it. To save you from googling, here’s some ways to create a patch:

#1. Use magit. To generate a quick diff patch, create a diff buffer by
#either =d d= on a change or commit; in the diff buffer, hit =W s=. To
#generate a patch from a commit or a range of commits, go on to a
#commit and do =W c c=. This puts the patch file(s) under the project
#root and isn’t very convenient, I usually just do =! ! git
#format-patch -<# of commits> --stdout > <file>.=

2. From command line, =git format-patch -<# of commits, e.g., 1> --stdout > <file>=

To send your patch, write an email to the mailing list: [[mailto:emacs-devel@gnu.org][emacs-devel]]. Drag your patch to the very end of the message, after signatures. Normally this is all it needs. Sometimes the message could be garbled; in that case, changing the message to plain text usually helps. You can also send a patch to debbugs, the bug tracker, if the patch is a bug fix. (See [[Debbugs]].)

* NEWS and manual

If you made a user-visible change, you should document this change in the NEWS file, possibly also update the manual. *You don’t need to worry about these until your patch is finalized, though. So maybe skip this section for now.* And Emacs maintainers will let you know what to do. Below is the relevant section in =/CONTRIBUTE=:

#+begin_quote
Any change that matters to end-users should have an entry in etc/NEWS.
Try to start each NEWS entry with a sentence that summarizes the entry
and takes just one line -- this will allow to read NEWS in Outline
mode after hiding the body of each entry.

Doc-strings should be updated together with the code.

New defcustom's should always have a ':version' tag stating the first
Emacs version in which they will appear.  Likewise with defcustom's
whose value is changed -- update their ':version' tag.

Think about whether your change requires updating the manuals.  If you
know it does not, mark the NEWS entry with "---".  If you know
that *all* the necessary documentation updates have been made as part
of your changes or those by others, mark the entry with "+++".
Otherwise do not mark it.

If your change requires updating the manuals to document new
functions/commands/variables/faces, then use the proper Texinfo
command to index them; for instance, use @vindex for variables and
@findex for functions/commands.  For the full list of predefined indices, see
https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Predefined-Indices.html
or run the shell command 'info "(texinfo)Predefined Indices"'.
#+end_quote

* Debbugs

[[https://debbugs.gnu.org][Debbugs]] is the bug tracker for GNU operating system. Here is [[https://debbugs.gnu.org/Emacs.html][Emacs’ debbugs home page]]. I’ve covered how to report a bug. After you sent the email reporting the bug, debbugs will reply to you a confirmation email with a bug number. Instead of replying to messages in the bug report, you can also comment by sending a message to =bug-number@gnu.debbugs.org=. When the bug is fixed, you can send a message to =<bug-number>-done@debbugs.gnu.org=, e.g., =40000-done@debbugs.gnu.org=. That closes the bug.

If you want to view currently pending bugs, you can either [[https://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs;max-bugs=100;base-order=1;bug-rev=1][browse online]], or view them in Emacs: install the package =debbugs= and =M-x debbugs-gnu=. You can click on bugs to view them, and view the conversation. You can even reply by =S w= on a message, and write your message in Emacs, and hit =C-c C-c= to send. Chose “mail client” and Emacs invokes your default mail application to send this mail. Hit =C-c C-k= to cancel the message.

* GNU ELPA

Have a good package? Add it to GNU ELPA! Pros:
- Get reviews from people that knows Emacs and Emacs Lisp best. 
- Instantly avaliable from vanilla Emacs. 
- You /can/ host your package on other places.
  Please see https://www.gnu.org/software/repo-criteria-evaluation.html
  for our comments on some used repo sites.
- You /can/ push to your package without review, and don’t need to follow Emacs conventions for commit messages.
- You need to sign the copyright assignment. And make sure all the contributors of your package (with significant contribution, i.e., ~15 lines) signs it.

View [[http://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/README][README]] for more detailed info.

[fn:1] Squash means combining several commits into one. It is easy to do with Magit: =l l= go to the log buffer; then go to the earliest commit you want to change, hit =r i=; hit =s= on the commits you wan to squash, commits marked with “s” will squash up. You can also use =M-n/p= to move the order of commits; then hit =C-c C-c= to edit the new commit message, and =C-c C-c= again to confirm.



-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Review a blog post about emacs-devel
  2020-04-30  2:28 ` Richard Stallman
@ 2020-04-30 15:19   ` Yuan Fu
  2020-04-30 16:42     ` Dmitry Gutov
  2020-04-30 15:52   ` Stefan Kangas
  2020-04-30 16:26   ` 조성빈
  2 siblings, 1 reply; 22+ messages in thread
From: Yuan Fu @ 2020-04-30 15:19 UTC (permalink / raw)
  To: Richard Stallman; +Cc: emacs-devel



> On Apr 29, 2020, at 10:28 PM, Richard Stallman <rms@gnu.org> wrote:
> 
> [[[ 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. ]]]
> 
> Would you please talk about "free software" or "libre software", not
> "open source”?
> [...]
> Also, please don't use GitHub as a standard of comparison.  That would
> promote GitHub, which is counter to what we aim to do.
> 

I removed “open source” since it’s not the main subject. I used GitHub as a comparison because it _is_ the most familiar workflow right now. I don’t think admitting the fact promotes GitHub. Also I wouldn’t say I used GitHub as a standard as comparison, but simply as another well-known workflow. Here is my edited first paragraph:

Emacs, /the/ editor we all use and love, has been running for decades, receiving contribution from hundreds of hackers along the way. Because it predates recent popular workflows (a.k.a GitHub and friends) by many years, you can’t do the usual thing—open issues, fork and make PR’s, etc. However, Emacs’s development workflow isn’t as tedious and difficult as many people imagines (in particular, you don’t need Gnus or deal with email in Emacs, or setup anything fancy).


> Please don't promote Emacs Lisp packages that we don't have papers
> to include in Emacs or GNU ELPA.  That includes Magit.
> 

I think we should promote all free software, non-selectively. Maybe the freedom of Magit is less secure because Jonas haven’t signed the assignment (yet); but I don’t think it’s enough difference to treat Magit differently. 

Yuan


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Review a blog post about emacs-devel
  2020-04-30  2:28 ` Richard Stallman
  2020-04-30 15:19   ` Yuan Fu
@ 2020-04-30 15:52   ` Stefan Kangas
  2020-04-30 16:26   ` 조성빈
  2 siblings, 0 replies; 22+ messages in thread
From: Stefan Kangas @ 2020-04-30 15:52 UTC (permalink / raw)
  To: Richard Stallman; +Cc: Yuan Fu, Emacs developers

Richard Stallman <rms@gnu.org> writes:

> Please don't promote Emacs Lisp packages that we don't have papers
> to include in Emacs or GNU ELPA.  That includes Magit.

What's the rationale for that recommendation?

Best regards,
Stefan Kangas



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Review a blog post about emacs-devel
  2020-04-30  2:28 ` Richard Stallman
  2020-04-30 15:19   ` Yuan Fu
  2020-04-30 15:52   ` Stefan Kangas
@ 2020-04-30 16:26   ` 조성빈
  2020-04-30 16:50     ` Stefan Kangas
  2 siblings, 1 reply; 22+ messages in thread
From: 조성빈 @ 2020-04-30 16:26 UTC (permalink / raw)
  To: rms; +Cc: Yuan Fu, Emacs developers

Richard Stallman <rms@gnu.org> 작성:

> [[[ 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. ]]]
>
> Would you please talk about "free software" or "libre software", not
> "open source"?
>
> The free software movement campaigns for software to respect users'
> freedom.  See https://gnu.org/philosophy/free-sw.html for the
> explanation of the four essential freedoms.  The ides of the free
> software movement is that denying a user these four freedoms is an
> injustice, and that we aim to end that injustice.  See
> https://gnu.org/philosophy/free-software-even-more-important.html.
>
> In 1998, people who disagreed with the free software movement's
> philosophy coined the term "open source" with the aim of causing the
> free software movement to be hidden behind a dense cloud of "open
> source" so that people would forget about our ideas.  Therefore, we
> must give high proprity to showing people that we shand for free
> software and _not_ for open source.  We never use the words "open
> source", or even "open" as an adjective applied to software,
> except to explain that it is NOT what we stand for.

 From what I read…

> The introduction of the term "open source software" was a deliberate  
> effort to make this field of endeavor more understandable to newcomers  
> and to business, which was viewed as necessary to its spread to a broader  
> community of users. The problem with the main earlier label, "free  
> software," was not its political connotations, but that—to newcomers—its  
> seeming focus on price is distracting.

Is it not true? (That’s from Christine Peterson.)

> See https://gnu.org/philosophy/open-source-misses-the-point.html
> for more explanation.
>
> Also, please don't use GitHub as a standard of comparison.  That would
> promote GitHub, which is counter to what we aim to do.

 From what I understand is that the blog post isn’t a GNU one but a
personal post? I don’t think it’s trying to speak for the GNU project.

> Please don't promote Emacs Lisp packages that we don't have papers
> to include in Emacs or GNU ELPA.  That includes Magit.

Same as above.

> Jonas Bernoulli recently asked for access to the Emacs repo.  That
> suggests that we have made progress on the needed papers and be able
> incorporate Magit into Emacs soon.  Then we could document it here,
> and in the Emacs manual.
>
> But we must not count that chicken until it hatches.  Therefore, I
> have commented out that text with #'s.  The idea is that it should not
> appear in the document we publish, but we should not lose it because
> we will want to include it in the future.
>
> I do not know Org mode syntax, so I may have made errors in editing it.
>
> Here is my edited draft.
>
>
>
> #+SETUPFILE: ../../setup.org
> #+TITLE: Contributing to Emacs
> #+DATE: <2020-04-25 Sat 16:59>
> #+TAGS: Emacs Hacker
> #+OPTIONS: toc:1
>
> Emacs, /the/ editor we all use and love, has been running for decades,  
> receiving contribution from hundreds of hackers along the way. But  
> because it predates “modern” libre software workflows by many years, you  
> can’t do the usual thing—open issues, fork and make PR’s, etc. However,  
> Emacs’s development workflow isn’t as tedious and difficult as many  
> people imagines (in particular, you don’t need Gnus or deal with email in  
> Emacs, or setup anything fancy). In this post I show what I’ve learned as  
> a Emacs new comer about participating the development of Emacs. I hope  
> that by sharing people what does contributing to Emacs look like, more  
> people knows what to expect and feels comfortable to join the development  
> of Emacs.
>
> * Report Emacs bug
>
> I won’t go into details here, because I think most people nowadays are  
> well educated by numerous libre projects on how to properly report a bug.  
> In the case of Emacs, in addition, you want to reproduce the bug with  
> vanilla Emacs, i.e., without your configurations. You can start one with  
> =emacs -Q=. And in Emacs type =M-x report-emacs-bug RET=, then =C-x M-i=  
> to use your mail application to send the bug report through email (Emacs  
> instructs you of all this). Then just wait for a developer to reply your  
> email (see? No setup needed). The only thing to remember is to make sure  
> you use “reply all” when replying emails (more on that in [[The mailing  
> list]].)
>
> * The mailing list
>
> We keep track of pending bug reports using the mailing list. A mailing  
> list has subscribers. When some one sends a mail to (or cc) the mailing  
> list address, the mailing list server forwards that message to every  
> subscribers, so every body sees your mail. To start a new thread, send a  
> mail to the mailing list server; to reply to someone’s message, simply  
> “reply all”. *Make sure you use “reply all” when replying to messages.*  
> If the message isn’t CC’ed to the mailing list server  
> (emacs-devel@gnu.org), other people on the list can’t see it.
>
> ** Subscribe to Emacs-devel mailing list
>
> Go to [[https://lists.gnu.org/mailman/listinfo/emacs-devel][Emacs-devel  
> Info Page]], and fill in the form to subscribe. Make sure you select “No”  
> for “Would you like to receive list mail batched in a daily digest?”. If  
> you select “Yes”, instead of receiving messages, you receive a “daily  
> digest” everyday, which is more or less useless becase 1) you don’t see  
> the full conversation, 2) you can’t participate the discussion.
>
> ** Tips
>
> Emacs-devel is busy, there are a couple dozen messages everyday, if you  
> don’t want your inbox flooded, you better setup a separate mail folder  
> for them. As an example, this is what I do on Gmail: I go to “Settings”,  
> “Filters and Blocked Addresses”, “Create a new filter”, filter any mail  
> that has the words “emacs-devel@gnu.org”, and asks Gmail to skip the  
> inbox and apply “emacs-devel” label. The effect is that all emacs-devel  
> messages don’t appear in your inbox and instead show up in emacs-devel  
> folder.
>
> ** No one replies?
>
> In general, give it a week or so before pinging your message. Normally  
> when no one reply to a new message, it is because people have seen it  
> don’t know enough to say anything intelligent about the topic. On the  
> other hand, don’t send a bug report without a patch to emacs-devel,  
> report it as a bug (even if you are not sure if it should be classified  
> as a bug, report it as a bug).
>
> * Get Emacs’ source
>
> - This is Emacs’ savannah homepage:  
> [[https://savannah.gnu.org/projects/emacs/]]
> - This is Emacs’ git source page:  
> http://git.savannah.gnu.org/cgit/emacs.git
>
> The home page tells you how to clone Emacs’ source:
> #+begin_src shell
> git clone -b master git://git.sv.gnu.org/emacs.git
> #+end_src
>
> Once you have the source, you can find most of the information mentioned  
> in this post in =/CONTRIBUTE=. For example, the first section clearly  
> demonstrates how to compile Emacs:
> #+begin_src shell
> # More info is in INSTALL.
> ./autogen.sh
> # You can use ./configure.sh --help to see the avaliable options.
> # This is the step where you enable/disable optional functionalities
> # like dynamic module, portable dumper, svg, etc.
> ./configure.sh
> make
> #+end_src
>
> And the executable is =/src/emacs=, welcome to the future (release)!
> # --enable-checking=yes --enable-check-lisp-object-type=yes
>
> * I have some code, what now?
> ** The copyright assignment
>
> Every non-trivial contribution to GNU Emacs needs to have a copyright  
> assignment signed. Basically by signing the assignment, you give the  
> copyright of your code to FSF. See more at  
> [[https://www.gnu.org/licenses/why-assign.en.html][Why Copyright  
> Assignment]]. You need to first check with your employer before signing  
> it. Most of the time it’s no problem. To sign the assignment, ask for a  
> form on the mailing list, and someone will send you the form. You fill it  
> in and send to the instructed “FSF clerk”, then he sends you the document  
> to sign, either by email or by mail. You sign it and send it back, and he  
> sends you the final document with FSF signature.
>
> ** Conventions in code
>
> - Write regular sentences in comment, i.e., with capitalization and  
> period. Format comments with =M-q= (~fill-paragraph~).
> - Comments should be in American English and with two spaces after every  
> sentence.
> - Don’t make comment lines longer than 70 columns.
>
> ** Conventions in commit messages
>
> The general format:
> # I added zero width space before each star to prevent Org from  
> considering them as headings
> #+begin_example
> Summary line (no ending period)
>
> Some more info (optional).
>
> ​* file: Change.
> ​* file (variable1): Change.
> ​* file (function1, function2, variable3): Same change.
> ​* file (variable1): Change 1.
> (function2): Change 2.
> (function1, macro2): Same change.
> #+end_example
>
> - The file path is relative to the source root, e.g.,  
> =/lisp/progmodes/gdb-mi.el=.
> - In =Change=, document /what/ changed, not /why/ the change is made.  
> /“Why”/ is better put in the comments.
> - For new function​/​variable​/​macro, It suffice to say “New  
> function​/​variable​/​macro”.
> - Don’t exceed 78 characters each line.
> - Try to use only ASCII characters (so people on limited terminals can  
> view these messages). For example, prefer straight quotes over curly  
> quotes.
> - Sames as comments—American English and two spaces after every sentence.
>
> ** Create patch and send it
>
> Create a single patch for each individual changes. Don’t send a patch  
> with three new features combined, that is harder to review; on the other  
> hand, don’t send a series of patches for a single feature, squash[fn:1]  
> them into one patch. Also, send your patch early and small and update  
> along the way, that also helps other people to review it. To save you  
> from googling, here’s some ways to create a patch:
>
> #1. Use magit. To generate a quick diff patch, create a diff buffer by
> #either =d d= on a change or commit; in the diff buffer, hit =W s=. To
> #generate a patch from a commit or a range of commits, go on to a
> #commit and do =W c c=. This puts the patch file(s) under the project
> #root and isn’t very convenient, I usually just do =! ! git
> #format-patch -<# of commits> --stdout > <file>.=
>
> 2. From command line, =git format-patch -<# of commits, e.g., 1> --stdout  
> > <file>=
>
> To send your patch, write an email to the mailing list:  
> [[mailto:emacs-devel@gnu.org][emacs-devel]]. Drag your patch to the very  
> end of the message, after signatures. Normally this is all it needs.  
> Sometimes the message could be garbled; in that case, changing the  
> message to plain text usually helps. You can also send a patch to  
> debbugs, the bug tracker, if the patch is a bug fix. (See [[Debbugs]].)
>
> * NEWS and manual
>
> If you made a user-visible change, you should document this change in the  
> NEWS file, possibly also update the manual. *You don’t need to worry  
> about these until your patch is finalized, though. So maybe skip this  
> section for now.* And Emacs maintainers will let you know what to do.  
> Below is the relevant section in =/CONTRIBUTE=:
>
> #+begin_quote
> Any change that matters to end-users should have an entry in etc/NEWS.
> Try to start each NEWS entry with a sentence that summarizes the entry
> and takes just one line -- this will allow to read NEWS in Outline
> mode after hiding the body of each entry.
>
> Doc-strings should be updated together with the code.
>
> New defcustom's should always have a ':version' tag stating the first
> Emacs version in which they will appear.  Likewise with defcustom's
> whose value is changed -- update their ':version' tag.
>
> Think about whether your change requires updating the manuals.  If you
> know it does not, mark the NEWS entry with "---".  If you know
> that *all* the necessary documentation updates have been made as part
> of your changes or those by others, mark the entry with "+++".
> Otherwise do not mark it.
>
> If your change requires updating the manuals to document new
> functions/commands/variables/faces, then use the proper Texinfo
> command to index them; for instance, use @vindex for variables and
> @findex for functions/commands.  For the full list of predefined indices,  
> see
> https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Predefined-Indices.html
> or run the shell command 'info "(texinfo)Predefined Indices"'.
> #+end_quote
>
> * Debbugs
>
> [[https://debbugs.gnu.org][Debbugs]] is the bug tracker for GNU operating  
> system. Here is [[https://debbugs.gnu.org/Emacs.html][Emacs’ debbugs home  
> page]]. I’ve covered how to report a bug. After you sent the email  
> reporting the bug, debbugs will reply to you a confirmation email with a  
> bug number. Instead of replying to messages in the bug report, you can  
> also comment by sending a message to =bug-number@gnu.debbugs.org=. When  
> the bug is fixed, you can send a message to  
> =<bug-number>-done@debbugs.gnu.org=, e.g., =40000-done@debbugs.gnu.org=.  
> That closes the bug.
>
> If you want to view currently pending bugs, you can either  
> [[https://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs;max-bugs=100;base-order=1;bug-rev=1][browse  
> online]], or view them in Emacs: install the package =debbugs= and =M-x  
> debbugs-gnu=. You can click on bugs to view them, and view the  
> conversation. You can even reply by =S w= on a message, and write your  
> message in Emacs, and hit =C-c C-c= to send. Chose “mail client” and  
> Emacs invokes your default mail application to send this mail. Hit =C-c  
> C-k= to cancel the message.
>
> * GNU ELPA
>
> Have a good package? Add it to GNU ELPA! Pros:
> - Get reviews from people that knows Emacs and Emacs Lisp best.
> - Instantly avaliable from vanilla Emacs.
> - You /can/ host your package on other places.
>   Please see https://www.gnu.org/software/repo-criteria-evaluation.html
>   for our comments on some used repo sites.
> - You /can/ push to your package without review, and don’t need to follow  
> Emacs conventions for commit messages.
> - You need to sign the copyright assignment. And make sure all the  
> contributors of your package (with significant contribution, i.e., ~15  
> lines) signs it.
>
> View  
> [[http://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/README][README]]  
> for more detailed info.
>
> [fn:1] Squash means combining several commits into one. It is easy to do  
> with Magit: =l l= go to the log buffer; then go to the earliest commit  
> you want to change, hit =r i=; hit =s= on the commits you wan to squash,  
> commits marked with “s” will squash up. You can also use =M-n/p= to move  
> the order of commits; then hit =C-c C-c= to edit the new commit message,  
> and =C-c C-c= again to confirm.
>
>
>
> -- 
> Dr Richard Stallman
> Chief GNUisance of the GNU Project (https://gnu.org)
> Founder, Free Software Foundation (https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)





^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Review a blog post about emacs-devel
  2020-04-30 15:19   ` Yuan Fu
@ 2020-04-30 16:42     ` Dmitry Gutov
  0 siblings, 0 replies; 22+ messages in thread
From: Dmitry Gutov @ 2020-04-30 16:42 UTC (permalink / raw)
  To: Yuan Fu, Richard Stallman; +Cc: emacs-devel

Hi Yuan,

On 30.04.2020 18:19, Yuan Fu wrote:

>> On Apr 29, 2020, at 10:28 PM, Richard Stallman <rms@gnu.org> wrote:
>>
>> [[[ 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. ]]]
>>
>> Would you please talk about "free software" or "libre software", not
>> "open source”?
>> [...]
>> Also, please don't use GitHub as a standard of comparison.  That would
>> promote GitHub, which is counter to what we aim to do.
>>
> 
> I removed “open source” since it’s not the main subject. I used GitHub as a comparison because it _is_ the most familiar workflow right now. I don’t think admitting the fact promotes GitHub. Also I wouldn’t say I used GitHub as a standard as comparison, but simply as another well-known workflow. Here is my edited first paragraph:
> 
> Emacs, /the/ editor we all use and love, has been running for decades, receiving contribution from hundreds of hackers along the way. Because it predates recent popular workflows (a.k.a GitHub and friends) by many years, you can’t do the usual thing—open issues, fork and make PR’s, etc. However, Emacs’s development workflow isn’t as tedious and difficult as many people imagines (in particular, you don’t need Gnus or deal with email in Emacs, or setup anything fancy).
> 
> 
>> Please don't promote Emacs Lisp packages that we don't have papers
>> to include in Emacs or GNU ELPA.  That includes Magit.
>>
> 
> I think we should promote all free software, non-selectively. Maybe the freedom of Magit is less secure because Jonas haven’t signed the assignment (yet); but I don’t think it’s enough difference to treat Magit differently.

These are good counter-points, so I think it's just fine if you make 
your post without honoring some of Richard's requests.

Swapping "open source" for "free software" is a good thing to do, though.



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Review a blog post about emacs-devel
  2020-04-30 16:26   ` 조성빈
@ 2020-04-30 16:50     ` Stefan Kangas
  2020-05-02 18:58       ` Yuan Fu
  0 siblings, 1 reply; 22+ messages in thread
From: Stefan Kangas @ 2020-04-30 16:50 UTC (permalink / raw)
  To: 조성빈; +Cc: Yuan Fu, Richard Stallman, Emacs developers

<pcr910303@icloud.com> writes:

> > The introduction of the term "open source software" was a deliberate
> > effort to make this field of endeavor more understandable to [...] business

> Is it not true? (That’s from Christine Peterson.)

Eric S. Raymond, the leader of the Open Source Initiative at the time
wrote: "the term [Free software] makes a lot of corporate types
nervous ... There's now a chance we can make serious gains in the
mainstream business world".[1]  So yes, it was an attempt to sweep
under the rug our ideas about user freedom to make it more palatable
to "corporate types" and big business.

The FSF has taken a principled stance against this:
https://www.gnu.org/philosophy/open-source-misses-the-point.html

Best regards,
Stefan Kangas

Footnotes:
1. See ESR's note titled "Goodbye, 'free software'; hello, 'open source'".



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Review a blog post about emacs-devel
  2020-04-30 16:50     ` Stefan Kangas
@ 2020-05-02 18:58       ` Yuan Fu
  2020-05-05  7:56         ` Jean-Christophe Helary
  0 siblings, 1 reply; 22+ messages in thread
From: Yuan Fu @ 2020-05-02 18:58 UTC (permalink / raw)
  To: Stefan Kangas
  Cc: Richard Stallman, 조성빈, Emacs developers

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

I will post my post. If anyone finds problems, I can always change it.

Here is the last draft.

Yuan


[-- Attachment #2: index.org --]
[-- Type: application/octet-stream, Size: 12658 bytes --]

#+SETUPFILE: ../../setup.org
#+TITLE: Contributing to Emacs
#+DATE: <2020-05-02 Sat 14:44>
#+TAGS: Emacs Hacker
#+OPTIONS: toc:1

Emacs, /the/ editor we all use and love, has been running for decades, receiving contribution from hundreds of hackers along the way. Because it predates recent popular workflows (a.k.a GitHub and friends) by many years, you can’t do the usual thing—open issues, fork and make PR’s, etc. However, Emacs’s development workflow isn’t as tedious and difficult as many people imagine (in particular, you don’t need Gnus or deal with email in Emacs, or set up anything fancy).

In this post, I show what I’ve learned as an Emacs newcomer about participating in the development of Emacs. I hope that by sharing people what does contributing to Emacs look like, more people know what to expect and feel comfortable to join the development of Emacs.

* Report Emacs bug

I won’t go into details here, because I think most people nowadays are well educated by numerous communities on how to report a bug properly. In the case of Emacs, in addition, you want to reproduce the bug with vanilla Emacs, i.e., without your configurations. You can start one with =emacs -Q=. And in Emacs type =M-x report-emacs-bug RET=, then =C-x M-i= to use your mail application to send the bug report through email (Emacs instructs you of all this). Then just wait for a developer to reply to your email (see? No setup needed). The only thing to remember is to make sure you use “reply all” when replying to emails (more on that in [[The mailing list]].)

** Report bugs with patch

If you found a bug and fixed it, you should send your patch as a bug report. Same as reporting a bug, use =M-x report-emacs-bug=, and append =[PATCH]= in front of the title, e.g., =[PATCH] Something doesn’t work=. And add your patch to your email. (See [[Create a patch and send it]].)

* The mailing list

The mailing list is the main channel for general discussion on Emacs development. A mailing list has subscribers. When someone sends a mail to (or cc) the mailing list address, the mailing list server forwards that message to every subscriber, so everybody sees your mail. To start a new thread, send a mail to the mailing list server; to reply to someone’s message, simply “reply all”. *Make sure you use “reply all” when replying to messages.* If the message isn’t CC’ed to the mailing list server (emacs-devel@gnu.org), other people on the list can’t see it.

** Subscribe to Emacs-devel mailing list

Go to [[https://lists.gnu.org/mailman/listinfo/emacs-devel][Emacs-devel Info Page]], and fill in the form to subscribe. Make sure you select “No” for “Would you like to receive list mail batched in a daily digest?”. If you select “Yes”, instead of receiving messages, you receive a “daily digest” every day, which is less useful because 1) you don’t see the full conversation, 2) you can’t participate in the discussion.

** Tips

Emacs-devel is busy, there are a few dozen messages every day. if you don’t want your inbox flooded, you better set up a separate mail folder for them. As an example, this is what I do on Gmail: I go to “Settings”, “Filters and Blocked Addresses”, “Create a new filter”, filter any mail that has the words “emacs-devel@gnu.org”, and asks Gmail to skip the inbox and apply “emacs-devel” label. The effect is that all emacs-devel messages don’t appear in your inbox and instead show up in the emacs-devel folder.

** No one replies?

In general, give it a week or so before pinging your message. Normally when no one replies to a new message, it is because people who have seen it don’t know enough to say anything intelligent about the topic. 

** Don’t send bugs to emacs-devel

Even with a patch, or you are not sure if it should be considered a bug (given you can reproduce it with vanilla Emacs), report it as a bug. See [[Report bugs with patch]] for detail.

* Get Emacs’ source

- This is Emacs’ savannah homepage: [[https://savannah.gnu.org/projects/emacs/][emacs - Summary]]
- This is Emacs’ git source page: [[http://git.savannah.gnu.org/cgit/emacs.git][emacs.git]]

The home page tells you how to clone Emacs’ source:
#+begin_src shell
git clone -b master git://git.sv.gnu.org/emacs.git
#+end_src

Once you have the source, you can find most of the information mentioned in this post in =/CONTRIBUTE=. For example, the first section demonstrates how to compile Emacs:
#+begin_src shell
# More info is in INSTALL.
./autogen.sh
# You can use ./configure.sh --help to see the available options.
# This is the step where you enable/disable optional functionalities
# like dynamic modules, portable dumper, SVG, etc.
./configure.sh
make
#+end_src

And the executable is =/src/emacs=, welcome to the future (release)! 
# --enable-checking=yes --enable-check-lisp-object-type=yes

* I have some code, what now?
** The copyright assignment

You don’t need a copyright assignment to send patches for review. But for the patch to merge into Emacs, it needs to have a copyright assignment signed if it is non-trivial (≥ 15 lines of code, as a rule of thumb). By signing the assignment, you give the copyright of your code to FSF. (See more at [[https://www.gnu.org/licenses/why-assign.en.html][Why Copyright Assignment]].) You need to first check with your employer before signing it. Most of the time it’s no problem. To sign the assignment, ask for a form on the mailing list, and someone will send it to you. You fill it in and send it to an “FSF clerk”, then he sends you the document to sign, either by email or by mail. You sign it and send it back, and he sends you the final document with an FSF signature on it. 

** Conventions in code

- Write regular sentences in comments, i.e., with capitalization and period. Fill comments with =M-q= (~fill-paragraph~).
- Comments should be in American English and with two spaces after every sentence.
- Don’t write over 80–90 columns (I don’t know if there is a hard limit, but in general try to keep in with the rest of the code).

** Conventions in commit messages

The general format:
# I added zero width space before each star to prevent Org from considering them as headings
#+begin_example
Summary line (no ending period)

Some more info (optional).

​* file1: Change.
​* file2 (variable1): Change.
​* file3 (function1, function2, variable3): Same change.
​* file4 (variable4): Change 1.
(function5): Change 2.
(function6, macro7): Same change.
#+end_example

- The file path is relative to the source root, e.g., =/lisp/progmodes/gdb-mi.el=.
- In =Change=, document /what/ changed, not /why/ the change is made. /“Why”/ is better put in the comments.
- For new function​/​variable​/​macro, It suffices to say “New function​/​variable​/​macro”.
- Don’t exceed 78 characters each line.
- Try to use only ASCII characters (so people on limited terminals can view these messages). For example, prefer straight quotes over curly quotes.
- Quote function​/​variable​/​macro like ='this'=​, not like =`this'=.
- Sames as comments—American English and two spaces after every sentence.
- Use the present tense.
- (tip) =M-x fill-paragraph= is your friend.

** Create a patch and send it

Create a single patch for each change. Don’t send a patch with three new features combined, that is harder to review; on the other hand, don’t send a series of patches for a single feature, squash[fn:1] them into one patch. Also, send your patch early and small and update along the way, that also helps other people to review it. To save you from googling, here are some ways to create a patch:

1. Use Magit. To generate a quick diff patch, open a diff buffer by either =d d= on a change or commit; in the diff buffer, hit =W s=. To generate a patch from a commit or a range of commits, go on to a commit and do =W c c=. This puts the patch file(s) under the project root and isn’t very convenient, I usually just do =! ! git format-patch -<# of commits> --stdout > <file>.=
2. From command line, =git format-patch -<# of commits, e.g., 1> --stdout > <file>=

To send your patch, write an email to the mailing list: [[mailto:emacs-devel@gnu.org][emacs-devel]]. Drag your patch to the end of the message after the signature. Normally this is all it needs. Sometimes the message could be garbled; in that case, changing the message to plain text usually helps. You can also send a patch to debbugs—the bug tracker—if the patch is a bug fix. (See [[Debbugs]].)

* NEWS and manual

If you made a user-visible change, you should document this change in the NEWS file, possibly also update the manual. *You don’t need to worry about these until your patch is finalized, though. So maybe skip this section for now.* And Emacs maintainers will let you know what to do. Below is the relevant section in =/CONTRIBUTE=:

#+begin_quote
Any change that matters to end-users should have an entry in etc/NEWS.
Try to start each NEWS entry with a sentence that summarizes the entry
and takes just one line -- this will allow to read NEWS in Outline
mode after hiding the body of each entry.

Doc-strings should be updated together with the code.

New defcustom's should always have a ':version' tag stating the first
Emacs version in which they will appear.  Likewise with defcustom's
whose value is changed -- update their ':version' tag.

Think about whether your change requires updating the manuals.  If you
know it does not, mark the NEWS entry with "=---=".  If you know
that *all* the necessary documentation updates have been made as part
of your changes or those by others, mark the entry with "=+++=".
Otherwise do not mark it.

If your change requires updating the manuals to document new
functions/commands/variables/faces, then use the proper Texinfo
command to index them; for instance, use @vindex for variables and
@findex for functions/commands.  For the full list of predefined indices, see
[[https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Predefined-Indices.html][Predefined Indices]] [fn:2]
or run the shell command 'info "(texinfo)Predefined Indices"'.
#+end_quote

* Debbugs

[[https://debbugs.gnu.org][Debbugs]] is the bug tracker for the GNU operating system. Here is [[https://debbugs.gnu.org/Emacs.html][Emacs’ debbugs home page]]. I’ve covered how to report a bug. After you sent the email reporting the bug, debbugs will send you a confirmation email with a bug number. Instead of replying to messages in the bug report, you can also comment by sending a message to =bug-number@gnu.debbugs.org=. When the bug is fixed, you can send a message to =<bug-number>-done@debbugs.gnu.org=, e.g., =40000-done@debbugs.gnu.org=. That closes the bug.

If you want to view currently open bugs, you can either [[https://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs;max-bugs=100;base-order=1;bug-rev=1][browse online]], or view them in Emacs: install the package =debbugs= and =M-x debbugs-gnu=. You can click on bugs to view the conversation. You can even reply by =S w= on a message, and write your message in Emacs, and hit =C-c C-c= to send. Chose “mail client” and Emacs invokes your default mail application to send this mail. Hit =C-c C-k= to cancel the message.

* GNU ELPA

Have a good package? Add it to GNU ELPA! 

Pros:
- Get reviews from people that know Emacs and Emacs Lisp best. 
- Instantly available from vanilla Emacs. 
- You /can/ host your package on other places, such as GitHub.
- You /can/ push to your package without review, and don’t need to follow Emacs conventions for commit messages.
Cons:
- You need to sign the copyright assignment. And make sure all the contributors of your package (with a significant contribution, i.e., ≥ ~15 lines) signs it.

View [[http://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/README][README]] for more detailed info.

* Footnotes

[fn:1] Squash means combining several commits into one. It is easy to do with Magit: =l l= go to the log buffer; then go to the earliest commit you want to change, hit =r i=; hit =s= on the commits you want to squash, commits marked with “s” will squash up. You can also use =M-n/p= to move the order of commits; then hit =C-c C-c= to edit the new commit message, and =C-c C-c= again to confirm.

[fn:2] It was =https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Predefined-Indices.html=, I shortened it for the layout.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Review a blog post about emacs-devel
  2020-05-02 18:58       ` Yuan Fu
@ 2020-05-05  7:56         ` Jean-Christophe Helary
  2020-05-07 19:40           ` Yuan Fu
  0 siblings, 1 reply; 22+ messages in thread
From: Jean-Christophe Helary @ 2020-05-05  7:56 UTC (permalink / raw)
  To: Emacs developers

Yuan,

I just remembered that you don't actually require magit to produce a diff under git in emacs.

What you need to do is just M-x vc-diff.

That produces a diff buffer that you can write wherever you want.

Since vc uses the vcs that's used for the given file, the diff will be the same as if you had used magit.


> On May 3, 2020, at 3:58, Yuan Fu <casouri@gmail.com> wrote:
> 
> I will post my post. If anyone finds problems, I can always change it.
> 
> Here is the last draft.
> 
> Yuan
> 
> <index.org>

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune





^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Review a blog post about emacs-devel
  2020-05-05  7:56         ` Jean-Christophe Helary
@ 2020-05-07 19:40           ` Yuan Fu
  2020-05-15  2:57             ` Yuan Fu
  0 siblings, 1 reply; 22+ messages in thread
From: Yuan Fu @ 2020-05-07 19:40 UTC (permalink / raw)
  To: Jean-Christophe Helary; +Cc: Emacs developers



> On May 5, 2020, at 3:56 AM, Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org> wrote:
> 
> Yuan,
> 
> I just remembered that you don't actually require magit to produce a diff under git in emacs.
> 
> What you need to do is just M-x vc-diff.
> 
> That produces a diff buffer that you can write wherever you want.
> 
> Since vc uses the vcs that's used for the given file, the diff will be the same as if you had used magit.

Thanks. I’ll try it out and add to my post.

Yuan


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Review a blog post about emacs-devel
  2020-05-07 19:40           ` Yuan Fu
@ 2020-05-15  2:57             ` Yuan Fu
  2020-05-15  5:55               ` Clément Pit-Claudel
  2020-05-15  6:52               ` Eli Zaretskii
  0 siblings, 2 replies; 22+ messages in thread
From: Yuan Fu @ 2020-05-15  2:57 UTC (permalink / raw)
  To: Jean-Christophe Helary; +Cc: Emacs developers

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

I think couple days ago someone (Joao?) read the copyright assignment and said FSF shares the copyright with the assignee, is that right? If so I should change the “give” in “By signing the assignment, you give the copyright of your code to FSF.” to “share”. 

Also, does that mean the assignee can change the license to public domain?

Yuan

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

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Review a blog post about emacs-devel
  2020-05-15  2:57             ` Yuan Fu
@ 2020-05-15  5:55               ` Clément Pit-Claudel
  2020-05-15 16:22                 ` Yuan Fu
  2020-05-15  6:52               ` Eli Zaretskii
  1 sibling, 1 reply; 22+ messages in thread
From: Clément Pit-Claudel @ 2020-05-15  5:55 UTC (permalink / raw)
  To: emacs-devel

On 14/05/2020 22.57, Yuan Fu wrote:
> I think couple days ago someone (Joao?) read the copyright assignment
> and said FSF shares the copyright with the assignee, is that right?
> If so I should change the “give” in “By signing the assignment, you
> give the copyright of your code to FSF.” to “share”.
> 
> Also, does that mean the assignee can change the license to public
> domain?

See https://www.fsf.org/bulletin/2014/spring/copyright-assignment-at-the-fsf:

> Sometimes contributors are concerned about giving up rights to their
> work. As the assignment is a gift to the free software community,
> they don't want it to come at the expense of having flexibility in
> the use of their own code. Thus, we grant back to contributors a
> license to use their work as they see fit. This means they are free
> to modify, share, and sublicense their own work under terms of their
> choice. This enables contributors to redistribute their work under
> another free software license. While this technically also permits
> distributing their work under a proprietary license, we hope they
> won't.




^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Review a blog post about emacs-devel
  2020-05-15  2:57             ` Yuan Fu
  2020-05-15  5:55               ` Clément Pit-Claudel
@ 2020-05-15  6:52               ` Eli Zaretskii
  2020-05-15 16:20                 ` Yuan Fu
  1 sibling, 1 reply; 22+ messages in thread
From: Eli Zaretskii @ 2020-05-15  6:52 UTC (permalink / raw)
  To: Yuan Fu; +Cc: jean.christophe.helary, emacs-devel

> From: Yuan Fu <casouri@gmail.com>
> Date: Thu, 14 May 2020 22:57:58 -0400
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> I think couple days ago someone (Joao?) read the copyright assignment and said FSF shares the copyright
> with the assignee, is that right? If so I should change the “give” in “By signing the assignment, you give the
> copyright of your code to FSF.” to “share”. 

I don't think "share" quite catches this, but IANAL.

Why do you need to include these details in a blog about Emacs?

> Also, does that mean the assignee can change the license to public domain?

Yes, but only for the version the assignee him/herself distributes,
not for the code contributed to Emacs.  AFAIU, at least.

In effect, AFAIU, the agreement splits the code into 2 separate
versions: one is distributed by Emacs under GPL, the other could be
distributed by the author under any license the author choses,
including a non-free one.



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Review a blog post about emacs-devel
  2020-05-15  6:52               ` Eli Zaretskii
@ 2020-05-15 16:20                 ` Yuan Fu
  0 siblings, 0 replies; 22+ messages in thread
From: Yuan Fu @ 2020-05-15 16:20 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Jean-Christophe Helary, emacs-devel

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



> On May 15, 2020, at 2:52 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Thu, 14 May 2020 22:57:58 -0400
>> Cc: Emacs developers <emacs-devel@gnu.org>
>> 
>> I think couple days ago someone (Joao?) read the copyright assignment and said FSF shares the copyright
>> with the assignee, is that right? If so I should change the “give” in “By signing the assignment, you give the
>> copyright of your code to FSF.” to “share”. 
> 
> I don't think "share" quite catches this, but IANAL.
> 
> Why do you need to include these details in a blog about Emacs?
> 

I mentioned that one needs to sign the assignment to get their code merged. Relevant paragraph:

You don’t need a copyright assignment to send patches for review. But for the patch to merge into Emacs, it needs to have a copyright assignment signed if it is non-trivial (≥ 15 lines of code, as a rule of thumb). By signing the assignment, you give the copyright of your code to FSF. (See more at [[https://www.gnu.org/licenses/why-assign.en.html][Why Copyright Assignment]].) You need to first check with your employer before signing it. Most of the time it’s no problem. To sign the assignment, ask for a form on the mailing list, and someone will send it to you. You fill it in and send it to an “FSF clerk”, then he sends you the document to sign, either by email or by mail. You sign it and send it back, and he sends you the final document with an FSF signature on it. 

Before now I thought by signing the assignment I give up my copyright and give to FSF. That didn’t bother me, but I’m sure there are people that doesn’t like to give up their copyright. I thought I ought to make clear that you don’t lose your copyright.

>> Also, does that mean the assignee can change the license to public domain?
> 
> Yes, but only for the version the assignee him/herself distributes,
> not for the code contributed to Emacs.  AFAIU, at least.
> 
> In effect, AFAIU, the agreement splits the code into 2 separate
> versions: one is distributed by Emacs under GPL, the other could be
> distributed by the author under any license the author choses,
> including a non-free one.

Thanks, I understand now.

Yuan

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

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Review a blog post about emacs-devel
  2020-05-15  5:55               ` Clément Pit-Claudel
@ 2020-05-15 16:22                 ` Yuan Fu
  0 siblings, 0 replies; 22+ messages in thread
From: Yuan Fu @ 2020-05-15 16:22 UTC (permalink / raw)
  To: Clément Pit-Claudel; +Cc: emacs-devel



> On May 15, 2020, at 1:55 AM, Clément Pit-Claudel <cpitclaudel@gmail.com> wrote:
> 
> On 14/05/2020 22.57, Yuan Fu wrote:
>> I think couple days ago someone (Joao?) read the copyright assignment
>> and said FSF shares the copyright with the assignee, is that right?
>> If so I should change the “give” in “By signing the assignment, you
>> give the copyright of your code to FSF.” to “share”.
>> 
>> Also, does that mean the assignee can change the license to public
>> domain?
> 
> See https://www.fsf.org/bulletin/2014/spring/copyright-assignment-at-the-fsf:
> 
>> Sometimes contributors are concerned about giving up rights to their
>> work. As the assignment is a gift to the free software community,
>> they don't want it to come at the expense of having flexibility in
>> the use of their own code. Thus, we grant back to contributors a
>> license to use their work as they see fit. This means they are free
>> to modify, share, and sublicense their own work under terms of their
>> choice. This enables contributors to redistribute their work under
>> another free software license. While this technically also permits
>> distributing their work under a proprietary license, we hope they
>> won’t.
> 
> 

Thanks, that’s very clear. I’ll link to that page in my post.

Yuan




^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2020-05-15 16:22 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-04-27 20:58 Review a blog post about emacs-devel Yuan Fu
2020-04-27 21:31 ` Noam Postavsky
2020-04-27 21:37   ` Yuan Fu
2020-04-29  6:33 ` Colin Baxter
2020-04-29  6:49 ` Jean-Christophe Helary
2020-04-29 14:08   ` Yuan Fu
2020-04-29 14:51   ` Drew Adams
2020-04-29 16:14     ` Yuan Fu
2020-04-30  2:28 ` Richard Stallman
2020-04-30 15:19   ` Yuan Fu
2020-04-30 16:42     ` Dmitry Gutov
2020-04-30 15:52   ` Stefan Kangas
2020-04-30 16:26   ` 조성빈
2020-04-30 16:50     ` Stefan Kangas
2020-05-02 18:58       ` Yuan Fu
2020-05-05  7:56         ` Jean-Christophe Helary
2020-05-07 19:40           ` Yuan Fu
2020-05-15  2:57             ` Yuan Fu
2020-05-15  5:55               ` Clément Pit-Claudel
2020-05-15 16:22                 ` Yuan Fu
2020-05-15  6:52               ` Eli Zaretskii
2020-05-15 16:20                 ` Yuan Fu

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.