Re: On Contributing To Emacs

Re: On Contributing To Emacs

[xenodasein--- via Emacs development discussions.]

Following article is from the original author of package straight.el.
They have taken the time and explained the situation in detail.
Hopefully we will apply the same level of attention to detail and
introspection when evaluating their thoughts and experiences.



It's very easy to say "the best choice would have been to fix
package.el", and a lot harder to put in the years of work required
to actually do that. From a purely technical point of view, I stand
by my decision to create a separate project as I believe it was a
much more effective way of quickly bringing about positive change
in the ecosystem, even if the end result was to merge things back
together in the long run. Obviously I didn't make the decision for
"career advancement", I made it for what I perceived to be the best
interest of the community. Reasonable people can disagree about what
is best for the community.

However, the problems go much deeper than that and I will elaborate
in the rest of this email.

> xenodasein:
> The problem is what lead you to do that, and what can emacs-devel
> do to prevent same thing from happening in the future.

Now this is something worth talking about. Yes, indeed, my experiences
with emacs-devel and the Emacs core development ecosystem in general
have been mostly negative, and have discouraged me from contributing
more than I absolutely had to. And yes, indeed, this feeling was part
of what motivated me to advocate for installing the absolute minimum
patch into Emacs core that would allow me to get on with straight.el
development.

The idea that there is something culturally wrong with the core
development of Emacs is not new; see Open Letter to the Emacs
Maintainers from 2016 for one example. But let me give my own
impressions.

- Development velocity is glacial. With releases around once per year
and there being no easily accessible distribution mechanism for
development updates, high-velocity projects or projects that must adapt
to a changing ecosystem (straight.el satisfies both of those criteria)
simply do not have a place in Emacs core as it exists today.
- The tools that must be used for contributing to Emacs are extremely
antiquated, and difficult to use for most developers, especially newer
ones who form the majority of the potential contributor base. I agree
with the points in the open letter linked above.
- The CLA signing process is inexplicably slow and opaque. With most
other projects, you sign the CLA in two minutes through a web interface
and you are on your way. With Emacs, you have to send an email, which
may or may not eventually receive a reply with the appropriate form,
which you then have to manually send back, and the whole process often
takes months with no communication whatsoever from the FSF about the
reason for the holdup, especially for contributors outside the United
States. I can point to a number of documented examples of this (i.e.
contributors waiting multiple months with no reply from the FSF,
despite many follow-ups).
- The mailing list which is the sole form of communication for Emacs
core development feels exclusionary to me. There is a heavy backbone
of established culture and conventions around the mailing list, which
are to my knowledge not documented anywhere and instead exist as
unwritten rules of discourse. And that's on top of the fact that all
development takes place via a mailing list in the first place, which
is a foreign concept to almost every new developer getting into
open-source. I can't point to any specific practice that seems
problematic, but the fact remains that while I have felt welcomed and
included into many other open-source communities, I have never felt
this way about my contributions to Emacs core.

I know for a fact that I am not the only person who has felt excluded
from contributing to Emacs because of one or more of these reasons,
especially the last. However, when these issues, especially the last,
are brought up, the response usually goes like this:
1. Can you point to a specific example of what the problem is?
2. Well, in that particular example, here's why how we do things is
perfectly reasonable.
3. Did you consider doing things this other way instead?

I understand this is well-intentioned, and it is usually done in an
unfailingly polite manner. But it has usually come across to me as
gaslighting, and it's my opinion that the culture surrounding Emacs
core development, in aggregate, strongly discourages new contributors
from joining the community, especially if they are a member of a group
which is traditionally underrepresented in open-source.

So if you want the long answer about why I developed straight.el
outside of Emacs core? It's because I didn't feel I was up to the task
of fixing the cultural problems above, and I don't feel comfortable
contributing to Emacs, or suggesting to others that they do so, until
they are fixed. Just fixing package management was hard enough, thank
you.

I hope this is helpful in understanding why things developed as they did,

Radon

Re: On Contributing To Emacs

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> - Development velocity is glacial. With releases around once per year
> and there being no easily accessible distribution mechanism for
> development updates, high-velocity projects or projects that must adapt
> to a changing ecosystem (straight.el satisfies both of those criteria)
> simply do not have a place in Emacs core as it exists today.

Why does a package manager need to constantly adapt to a changing
ecosystem, or be developed at a very high velocity?

That doesn't make sense to me: package managers are one of the
cornerstones of an ecosystem, so I would expect that ecosystems tend to
adapt to their package managers, and not the other way around.

> - The tools that must be used for contributing to Emacs are extremely
> antiquated, and difficult to use for most developers, especially newer
> ones who form the majority of the potential contributor base.

That is simply untrue.

> - The CLA signing process is inexplicably slow and opaque. With most
> other projects, you sign the CLA in two minutes through a web interface
> and you are on your way. With Emacs, you have to send an email, which
> may or may not eventually receive a reply with the appropriate form,
> which you then have to manually send back, and the whole process often
> takes months with no communication whatsoever from the FSF about the
> reason for the holdup, especially for contributors outside the United
> States. I can point to a number of documented examples of this (i.e.
> contributors waiting multiple months with no reply from the FSF,
> despite many follow-ups).

I have actually seen (in person) various problems resulting from signing
legal documents via online forms destroy pieces of software, so I
strongly support the FSF's position on how the copyright assignment must
be signed.

> - The mailing list which is the sole form of communication for Emacs
> core development feels exclusionary to me. There is a heavy backbone
> of established culture and conventions around the mailing list, which
> are to my knowledge not documented anywhere and instead exist as
> unwritten rules of discourse.

Why not ask?

Re: On Contributing To Emacs

[xenodasein--- via Emacs development discussions.]

Dec 28, 2021, 15:13 by Po Lu:

> Why does a package manager need to constantly adapt to a changing
> ecosystem, or be developed at a very high velocity?
> ...
> That doesn't make sense to me: package managers are one of the
> cornerstones of an ecosystem, so I would expect that ecosystems tend to
> adapt to their package managers, and not the other way around.
> ...
> That is simply untrue.
> ...
> I have actually seen (in person) various problems resulting from signing
> legal documents via online forms destroy pieces of software, so I
> strongly support the FSF's position on how the copyright assignment must
> be signed.
> ...
> Why not ask?
> ...
>

The point isn't author's complete non-falsifiable accuracy.  So thanks for being
contrarian for the sake of being contrarian, and proving their point, I guess.

Re: On Contributing To Emacs

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

>> - The tools that must be used for contributing to Emacs are extremely
>> antiquated, and difficult to use for most developers, especially newer
>> ones who form the majority of the potential contributor base.
>
> That is simply untrue.

We have a lot of evidence for this being the case from community
interactions such as this one.  Attracting more contributors is one of
the main reasons why we are looking into sourcehut (or some other
forge).

For my part, I'm not just fine with our tools, but actually prefer them
to the forge workflow.  But my thoughts and preferences are not the key
thing here, but what most other prospective contributors think.

This is why we want to provide two types of workflow: both the forge
one, and something close enough to the one we have now.  The hope is
that sourcehut (or some other forge) will eventually provide this.

Re: On Contributing To Emacs

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> This is why we want to provide two types of workflow: both the forge
> one, and something close enough to the one we have now.  The hope is
> that sourcehut (or some other forge) will eventually provide this.

Have you looked into the debbugs frontend the Guix developers seem to be
using?  It looks similar to SourceHut and can probably be extended to
suit other people's needs, such as with the ability to submit bug
reports and patches.

Does anyone want to work on this?
Thanks.

Re: On Contributing To Emacs

[Philip Kaludercic]

Po Lu <luangruo@yahoo.com> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> This is why we want to provide two types of workflow: both the forge
>> one, and something close enough to the one we have now.  The hope is
>> that sourcehut (or some other forge) will eventually provide this.
>
> Have you looked into the debbugs frontend the Guix developers seem to be
> using?  It looks similar to SourceHut and can probably be extended to
> suit other people's needs, such as with the ability to submit bug
> reports and patches.

You mean https://issues.guix.gnu.org/?  That would only be part of what
SourceHut is supposed to provide (a front-end for the issue tracker).

> Does anyone want to work on this?
> Thanks.
>
>

-- 
	Philip Kaludercic

Re: On Contributing To Emacs

[Po Lu]

Philip Kaludercic <philipk@posteo.net> writes:

> You mean https://issues.guix.gnu.org/?  That would only be part of what
> SourceHut is supposed to provide (a front-end for the issue tracker).

I thought we wanted it so we could provide an issue tracker accessible
from the web and the ability to submit patches from a web interface.

The former is already possible, and the latter could probably be
implemented fairly easily should someone want to work on it.

Re: On Contributing To Emacs

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> You mean https://issues.guix.gnu.org/?  That would only be part of what
>> SourceHut is supposed to provide (a front-end for the issue tracker).
>
> I thought we wanted it so we could provide an issue tracker accessible
> from the web and the ability to submit patches from a web interface.

And basic things like (un)subscribing to a bug, subcomponents (with
subscriptions), not having to CC every participant which is not already
on the CC list of the mail you are responding to, etc.

Extra points if the new system does not require to read a manual for
closing, reopening or categorizing bugs. Oh, and dispense with the
"archiving" thing.

For now let's put aside cross-references between commits, bugs, patch
submissions and C.I. runs as something too modern to bear.

> The former is already possible,

It is already possible on debbugs.gnu.org, for some sufficiently broad
definition of "possible".

> and the latter could probably be
> implemented fairly easily should someone want to work on it.

Famous last words.

Re: On Contributing To Emacs

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> And basic things like (un)subscribing to a bug, subcomponents (with
> subscriptions),

Don't we already have that?  (Where you give debbugs an incantation
along the lines of "Package: emacs,component-here", and it will DTRT.)

It's just that not many people make use of it.

> not having to CC every participant which is not already on the CC list
> of the mail you are responding to, etc.

I never found that to be a problem with debbugs.  I think you only have
to CC the bug address.

> Extra points if the new system does not require to read a manual for
> closing, reopening or categorizing bugs.

I haven't seen such a system to date, and that includes SourceHut.

> For now let's put aside cross-references between commits, bugs, patch
> submissions and C.I. runs as something too modern to bear.

FWIW, My experience is that stuff always gets in the way.

At my shop we used to have a cron job that searched through VCS log
messages looking for the text "resolves: <bug number>", closing the
corresponding tickets on Trac.

Eventually, we realized that you cannot rely on a commit to always solve
an issue, and that it is usually better to wait for whoever discovered
the bug to verify that it was fixed before calling it "resolved".

Also, I don't understand how it makes sense for CI to run on a bug
report.

> It is already possible on debbugs.gnu.org, for some sufficiently broad
> definition of "possible".

It's not possible on debbugs.gnu.org, which doesn't let you submit
reports from a web browser.

> Famous last words.

No.  If you can submit comments, you can send e-mail, which means adding
an attachment to the email should be a fairly trivial task.

Re: On Contributing To Emacs

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> And basic things like (un)subscribing to a bug, subcomponents (with
>> subscriptions),
>
> Don't we already have that?  (Where you give debbugs an incantation
> along the lines of "Package: emacs,component-here", and it will DTRT.)
>
> It's just that not many people make use of it.

Maybe that hints at an usability problem?

>> not having to CC every participant which is not already on the CC list
>> of the mail you are responding to, etc.
>
> I never found that to be a problem with debbugs.  I think you only have
> to CC the bug address.

Sadly, no. If I submit a bug and get responses to the original report
from Alice and Bob, then I answer Alice's message, Bob wont see it
unless I add his address to the CC list on my message to Alice.

>> Extra points if the new system does not require to read a manual for
>> closing, reopening or categorizing bugs.
>
> I haven't seen such a system to date, and that includes SourceHut.

Well, just to name an example, bugzilla which is both popular and
ancient, hardly needs any instructions to do those trivial things.

>> For now let's put aside cross-references between commits, bugs, patch
>> submissions and C.I. runs as something too modern to bear.
>
> FWIW, My experience is that stuff always gets in the way.

In my experience is really convenient.

>> It is already possible on debbugs.gnu.org, for some sufficiently broad
>> definition of "possible".
>
> It's not possible on debbugs.gnu.org, which doesn't let you submit
> reports from a web browser.

The mentioned guix debbugs frontend doesn't allow that either. It says
it is disabled, the question is: why?

>> Famous last words.
>
> No.  If you can submit comments, you can send e-mail, which means adding
> an attachment to the email should be a fairly trivial task.

You can attach cat pics too :-) The hard part is not attaching patches,
the hard part is to recognize and handle them so they are automatically
available to the related tools (conflict detection, quick merge, run
C.I. on the patch, etc.)

Re: On Contributing To Emacs

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Maybe that hints at an usability problem?

No, it probably hints that nobody finds it neccessary to make use of.

> Sadly, no. If I submit a bug and get responses to the original report
> from Alice and Bob, then I answer Alice's message, Bob wont see it
> unless I add his address to the CC list on my message to Alice.

Okay, but how is that a problem?  Everyone knows to click "Reply All",
which is present even in webmail, and if someone doesn't, he usually
remembers after being asked once.

> Well, just to name an example, bugzilla which is both popular and
> ancient, hardly needs any instructions to do those trivial things.

With Bugzilla, you typically have to read the user guide and several
pieces of project-specific documentation documenting their conventions
before you can do something as "trivial" as report a bug.

> The mentioned guix debbugs frontend doesn't allow that either.

It does, just not the Guix instance.

> You can attach cat pics too :-) The hard part is not attaching patches,
> the hard part is to recognize and handle them so they are automatically
> available to the related tools (conflict detection, quick merge, run
> C.I. on the patch, etc.)

Why would anyone want to run CI on a patch sent from an arbitrary
source?  That seems prone to abuse, and also a waste of electricity.

Detecting conflicts should be trivial, but I don't understand what you
refer to by "quick merge".

Re: On Contributing To Emacs

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> Maybe that hints at an usability problem?
>
> No, it probably hints that nobody finds it neccessary to make use of.

Knowing that Emacs is composed by multiple parts largely unrelated one
to another, I think that the people who maintain Org would be happy to
not receive bug reports about Gnus, and so on.

The problem is that either it is not possible or it is too difficult to
set up, AFAIK.

>> Sadly, no. If I submit a bug and get responses to the original report
>> from Alice and Bob, then I answer Alice's message, Bob wont see it
>> unless I add his address to the CC list on my message to Alice.
>
> Okay, but how is that a problem?  Everyone knows to click "Reply All",
> which is present even in webmail, and if someone doesn't, he usually
> remembers after being asked once.

How "Reply All" helps if Bob's address is not on the message I received
from Alice?

>> Well, just to name an example, bugzilla which is both popular and
>> ancient, hardly needs any instructions to do those trivial things.
>
> With Bugzilla, you typically have to read the user guide and several
> pieces of project-specific documentation documenting their conventions
> before you can do something as "trivial" as report a bug.

I have quite a few bugs reported on non-trivial bugzilla instances (gcc,
just to name one) and never had to read any instructions.

>> The mentioned guix debbugs frontend doesn't allow that either.
>
> It does, just not the Guix instance.

You stripped out this important part of my message "it is disabled, the
question is: why?"

>> You can attach cat pics too :-) The hard part is not attaching patches,
>> the hard part is to recognize and handle them so they are automatically
>> available to the related tools (conflict detection, quick merge, run
>> C.I. on the patch, etc.)
>
> Why would anyone want to run CI on a patch sent from an arbitrary
> source?

Why do you assume that the source is arbitrary?

> Detecting conflicts should be trivial, but I don't understand what you
> refer to by "quick merge".

Merging by issuing a simple command, like pushing a button on a web
interface or sending an email with a keyword.

Re: On Contributing To Emacs

[Stefan Kangas]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Knowing that Emacs is composed by multiple parts largely unrelated one
> to another, I think that the people who maintain Org would be happy to
> not receive bug reports about Gnus, and so on.
>
> The problem is that either it is not possible or it is too difficult to
> set up, AFAIK.

Yes, doing that is pretty much a non-starter with debbugs.

>> Okay, but how is that a problem?  Everyone knows to click "Reply All",
>> which is present even in webmail, and if someone doesn't, he usually
>> remembers after being asked once.

Unfortunately, that doesn't help.  First, not everyone knows that, so we
need to constantly tell people about it.

Second, we often have replies that don't land in the bug tracker because
someone forgot or accidentally hit "Reply" instead of "Reply to all".
I've seen this happens with all kinds of users, including regular
contributors.

Re: On Contributing To Emacs

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> Yes, doing that is pretty much a non-starter with debbugs.

Gnus already does that, and at least CC Mode and Org Mode have their own
separate bug trackers.

It's not a non-starter, just a little-known feature.  I think the Debian
folks also make use of it quite well.

> Second, we often have replies that don't land in the bug tracker because
> someone forgot or accidentally hit "Reply" instead of "Reply to all".
> I've seen this happens with all kinds of users, including regular
> contributors.

I don't think those cases are very common, and having every message land
in the bug tracker isn't that important either.

Re: On Contributing To Emacs

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> Gnus already does that, and at least CC Mode and Org Mode have their own
> separate bug trackers.

Indeed.  The experience is less than satisfactory.

> I don't think those cases are very common,

Well, I don't know what to tell you.  FWIW, my experience is that they
are very common.  Take that as you will.

>  and having every message land
> in the bug tracker isn't that important either.

The work is lost, so I think it is better if we can avoid it.

Re: On Contributing To Emacs

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> Indeed.  The experience is less than satisfactory.

Why is that?  It could be a general problem that SourceHut wouldn't
solve either.

> The work is lost, so I think it is better if we can avoid it.

The message might be lost from the tracker, but it at least reaches the
intended recipient(s), so I think the amount of work that is lost is
rather small.

Re: On Contributing To Emacs

[Dmitry Gutov]

On 29.12.2021 16:46, Po Lu wrote:
> Óscar Fuentes <ofv@wanadoo.es> writes:
> 
>> Maybe that hints at an usability problem?
> 
> No, it probably hints that nobody finds it neccessary to make use of.
> 
>> Sadly, no. If I submit a bug and get responses to the original report
>> from Alice and Bob, then I answer Alice's message, Bob wont see it
>> unless I add his address to the CC list on my message to Alice.
> 
> Okay, but how is that a problem?  Everyone knows to click "Reply All",
> which is present even in webmail, and if someone doesn't, he usually
> remembers after being asked once.

Some people plainly refuse to consider usability problems with our 
current workflow, or try to learn from alternatives.

Nothing new here, but I'm sad to see that every time.

>> Well, just to name an example, bugzilla which is both popular and
>> ancient, hardly needs any instructions to do those trivial things.
> 
> With Bugzilla, you typically have to read the user guide and several
> pieces of project-specific documentation documenting their conventions
> before you can do something as "trivial" as report a bug.

That's obviously false.

I've reported bugs on Mozilla's bugzilla a few times and never had to 
read any manuals to do that.

Saw many reports from even less informed users, too.

Re: On Contributing To Emacs

[xenodasein--- via Emacs development discussions.]

Dec 29, 2021, 18:16 by dgutov@yandex.ru:

> Some people plainly refuse to consider usability problems with our current workflow, or try to learn from alternatives.
>
> Nothing new here, but I'm sad to see that every time.
>

I really can't wrap my head around that kind of "everything is perfect"
attitude.  It's paradoxical.
Can think of an improvement?  Say it.
Is it a non-priority?  add-to-list
Why waste time arguing otherwise?

Re: On Contributing To Emacs

[Eli Zaretskii]

> Date: Wed, 29 Dec 2021 16:45:34 +0100 (CET)
> From: xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> 
> Dec 29, 2021, 18:16 by dgutov@yandex.ru:
> 
> > Some people plainly refuse to consider usability problems with our current workflow, or try to learn from alternatives.
> >
> > Nothing new here, but I'm sad to see that every time.
> >
> 
> I really can't wrap my head around that kind of "everything is perfect"
> attitude.  It's paradoxical.
> Can think of an improvement?  Say it.
> Is it a non-priority?  add-to-list
> Why waste time arguing otherwise?

Please respect the views of others as much as you'd like others to
respect yours.  Even (and especially) if you disagree with their
views.  That includes (a) assuming they write in good faith, not to
"waste your time"; and (b) not representing their views as something
obviously non-sensical.

TIA

Re: On Contributing To Emacs

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> That's obviously false.

Let's use WebKit an an example: to report a bug, you have to decide
which component to report a bug to first (or what "New Bugs" is for),
which means you have to read their Bug Writing Guidelines and their
"writing a good bug report" guidelines.

Re: On Contributing To Emacs

[Dmitry Gutov]

On 30.12.2021 04:09, Po Lu wrote:
> Dmitry Gutov<dgutov@yandex.ru>  writes:
> 
>> That's obviously false.
> Let's use WebKit an an example: to report a bug, you have to decide
> which component to report a bug to first (or what "New Bugs" is for),
> which means you have to read their Bug Writing Guidelines and their
> "writing a good bug report" guidelines.

That's orthogonal to the rest of bug tracker's usability: it cannot 
determine for you which component the report relates to.

Some make an attempt, though, by suggesting some options based on the 
issue description (we, with Debbugs, do not).

Also modern bug trackers have templates for issue submission forms with 
multiple steps which can guide the user to make a better submission 
(e.g. start with 'emacs -Q', include reproduction steps, maybe consult 
etc/DEBUG, etc).

And they can also pick from a list of components that they can *actually 
see* in a dropdown list or whatever. If they don't, volunteers usually 
do that job for them during triage.

IOW, while there still is no silver bullet for bug reporting, it's very 
hard to do worse than Debbugs, even if we just pick among popular bug 
tracker at random.

Re: On Contributing To Emacs

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> IOW, while there still is no silver bullet for bug reporting, it's
> very hard to do worse than Debbugs, even if we just pick among popular
> bug tracker at random.

Emacs has `report-emacs-bug' (which is also in the menu bar), which
makes this job trivial.

Re: On Contributing To Emacs

[Dmitry Gutov]

On 30.12.2021 17:00, Po Lu wrote:
> Dmitry Gutov<dgutov@yandex.ru>  writes:
> 
>> IOW, while there still is no silver bullet for bug reporting, it's
>> very hard to do worse than Debbugs, even if we just pick among popular
>> bug tracker at random.
> Emacs has `report-emacs-bug' (which is also in the menu bar), which
> makes this job trivial.

No it doesn't. I even mentioned some differences in my previous email.

And again, there's nothing special in 'report-emacs-bug'.

This discussion has mentioned other parts of Debbugs, however, which are 
more noticeably broken by contemporary standards.

Re: On Contributing To Emacs

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> This discussion has mentioned other parts of Debbugs, however, which
> are more noticeably broken by contemporary standards.

You mean, the ability to have actual threading in bug reports?  I'd say
that's a feature.

Besides, Debian people seem to be doing fine.

Re: On Contributing To Emacs

[Dmitry Gutov]

On 31.12.2021 03:45, Po Lu wrote:
> You mean, the ability to have actual threading in bug reports?

No, I don't mean that.

Re: On Contributing To Emacs

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> No, I don't mean that.

Then I don't see anything else that someone actually demonstrated to be
substandard.

Re: On Contributing To Emacs

[Dmitry Gutov]

On 31.12.2021 04:12, Po Lu wrote:
> Dmitry Gutov<dgutov@yandex.ru>  writes:
> 
>> No, I don't mean that.
> Then I don't see anything else that someone actually demonstrated to be
> substandard.

You omit quotes and ignore sentences, even in my brief recent emails 
which I tried to keep short and to the point.

I don't think I'm able to help you see that "anything else".

Re: On Contributing To Emacs

[Sean Whitton]

On Fri 31 Dec 2021 at 08:45am +08, Po Lu wrote:

> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>> This discussion has mentioned other parts of Debbugs, however, which
>> are more noticeably broken by contemporary standards.
>
> You mean, the ability to have actual threading in bug reports?  I'd say
> that's a feature.
>
> Besides, Debian people seem to be doing fine.

Not really -- we can't really quit debbugs because it has special
features to track how we do versions and releases, and we are highly
reliant on those.  I think that if that wasn't the case, there's a good
chance we'd be using something else by now.

I am someone who, like you, prefers as much as possible to be actual
e-mail messages, but debbugs is just not that good!

-- 
Sean Whitton

Re: On Contributing To Emacs

[Stefan Monnier]

> Not really -- we can't really quit debbugs because it has special
> features to track how we do versions and releases, and we are highly
> reliant on those.

That's news to me.  Could you give details of what you mean?


        Stefan

Debian's use of debbugs (was Re: On Contributing To Emacs)

[Sean Whitton]

Hello Stefan,

On Sat 01 Jan 2022 at 12:38pm -05, Stefan Monnier wrote:

>> Not really -- we can't really quit debbugs because it has special
>> features to track how we do versions and releases, and we are highly
>> reliant on those.
>
> That's news to me.  Could you give details of what you mean?

It's mostly about how we automate migrating packages from our 'unstable'
distribution to the 'testing' distribution, and the process of
automatically dropping buggy packages from 'testing' in order to allow
other packages to migrate.  We can specify particular version numbers of
packages in which a bug is present or absent, and debbugs looks at the
versions in 'unstable' and 'testing' and figures out where the bug is
present and draws a graph, which is very helpful when triaging.

There are also some tags to override this logic -- for example, perhaps
the same version of the package is in 'unstable' and 'testing', but the
bug only occurs in 'testing'.  If the bug is properly tagged, the
testing migration tool can determine what other packages it might be
able to migrate unstable->testing if it were to remove the buggy package
from 'testing', and things like that.

I don't work much in release-related parts of Debian, so I am not sure
how much of the logic is on the debbugs side and how much is in the
testing migration scripts, but there's certainly some in both.  As a
package maintainer, you just try to set the correct debbugs metadata and
package dependency metadata, and the scripts are able to figure out good
migration solutions.

-- 
Sean Whitton

Re: Debian's use of debbugs (was Re: On Contributing To Emacs)

[Stefan Monnier]

>> That's news to me.  Could you give details of what you mean?
> It's mostly about how we automate migrating packages from our 'unstable'
> distribution to the 'testing' distribution, and the process of
[...]

Ah, I was confused I didn't notice you were talking about Debian rather
than Emacs.  Sorry 'bout the noise, and thanks for the detailed
explanation.  I didn't realize Debian relied so directly on Debbugs
for that.

[ I suspect that if Debian decided to use a different issue racking
  system they wouldn't have much difficulty getting similar info from
  it, tho it would likely require a fair bit of tweaking/rewriting
  existing scripts.  ]


        Stefan

Re: On Contributing To Emacs

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

  > Let's use WebKit an an example: to report a bug, you have to decide
  > which component to report a bug to first (or what "New Bugs" is for),
  > which means you have to read their Bug Writing Guidelines and their
  > "writing a good bug report" guidelines.

We could do this -- it would take some work.  What I am not sure of
is whether it would be an improvement.  It would be useful to
get people to read our own bug reporting guidelines, but it would
discourage some people.  Which effect is bigger?  It would be hard
to predict or even to measure.

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

Re: On Contributing To Emacs

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

>   > Let's use WebKit an an example: to report a bug, you have to decide
>   > which component to report a bug to first (or what "New Bugs" is for),
>   > which means you have to read their Bug Writing Guidelines and their
>   > "writing a good bug report" guidelines.

> We could do this -- it would take some work.  What I am not sure of is
> whether it would be an improvement.  It would be useful to get people
> to read our own bug reporting guidelines, but it would discourage some
> people.  Which effect is bigger?  It would be hard to predict or even
> to measure.

What I was trying to say is that with emacsbug and friends, reporting a
bug with Emacs is much easier for new users than most projects running
Bugzilla, such as WebKit.

Thanks.

Re: On Contributing To Emacs

[Philip Kaludercic]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> The idea that there is something culturally wrong with the core
> development of Emacs is not new; see Open Letter to the Emacs
> Maintainers from 2016 for one example. But let me give my own
> impressions.

Does someone have a link to this open letter? All I can find is
https://medium.com/@fommil/open-letter-to-the-emacs-maintainers-226cb67a961f,
and that article was removed.

If the article is from 2016, I don't assume that it brings up anything I
haven't heard of before, but I'd still like to give it a read.

> I understand this is well-intentioned, and it is usually done in an
> unfailingly polite manner. But it has usually come across to me as
> gaslighting, and it's my opinion that the culture surrounding Emacs
> core development, in aggregate, strongly discourages new contributors
> from joining the community, especially if they are a member of a group
> which is traditionally underrepresented in open-source.

(Like people who prefer to not use GitHub/GitHub-like workflows?)

-- 
	Philip Kaludercic

Re: On Contributing To Emacs

[xenodasein--- via Emacs development discussions.]

Dec 28, 2021, 15:53 by philipk@posteo.net:

> Does someone have a link to this open letter? All I can find is
> https://medium.com/@fommil/open-letter-to-the-emacs-maintainers-226cb67a961f,
> and that article was removed.
>

https://web.archive.org/web/20171022141330/https://medium.com/@fommil/open-letter-to-the-emacs-maintainers-226cb67a961f

Re: On Contributing To Emacs

[Stefan Monnier]

> It's very easy to say "the best choice would have been to fix
> package.el", and a lot harder to put in the years of work required
> to actually do that. From a purely technical point of view, I stand
> by my decision to create a separate project as I believe it was a
> much more effective way of quickly bringing about positive change
> in the ecosystem, even if the end result was to merge things back
> together in the long run.

FWIW, I fully agree and I think I would have done exactly the same
thing.  On many other occasions I've basically done the same.
It's actually the standard way for things to happen in Emacs (and
probably in many other projects): you first start from scratch based on
a new idea, see where it leads you.  Later on, once the idea has
matured, you may want to go back and see if it can be better integrated
with existing elements, but doing so from the start is rarely a good idea.


        Stefan

Re: On Contributing To Emacs

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

  > - The CLA signing process is inexplicably slow and opaque.

Some projects use a document that they call a "CLA".  We ask for a
copyright assignment.  It is a legal document, and to make it suitable
to rely on in court, we want it to be properly signed.
Thus we follow legal advice from lawyers.

However, this process has speeded up greatly in the past couple or
years.  If you don't get a reply in two weeks, you should ask again,
and in another two weeks, please tell the Emacs maintainers.  We will
get things moving.


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

Re: On Contributing To Emacs

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> However, this process has speeded up greatly in the past couple or
> years.  If you don't get a reply in two weeks, you should ask again,
> and in another two weeks, please tell the Emacs maintainers.  We will
> get things moving.

You're saying that as if having a two week turnaround is an achievement
instead of the failure that it is.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: On Contributing To Emacs

[Akira Kyle]

On Wed, Dec 29, 2021 at 7:44 AM Lars Ingebrigtsen <larsi@gnus.org> wrote:
>
> > However, this process has speeded up greatly in the past couple or
> > years.  If you don't get a reply in two weeks, you should ask again,
> > and in another two weeks, please tell the Emacs maintainers.  We will
> > get things moving.
>
> You're saying that as if having a two week turnaround is an achievement
> instead of the failure that it is.
>

Indeed. Speaking from my own experience, I've been putting off getting
my assignment done because apparently, as a university student, I need
to do extra work and find the right person at my school to also sign
off on this. Since navigating the attitudes of the fsf versus my
school towards copyright has been incredibly low on the list of things
I'd like to spend my free time on, I have yet to follow through. As
such I've been less inclined to spend any of my emacs hacking time on
things that touch emacs source code as I know trying to get patches
sent in will require me doing this drudge work first and I'm already
at my limit of ~15loc. It is really a shame that this process is so
time consuming and discouraging for someone like me.

I also have a question that I might as well ask here in case anyone
knows the answer: part of my funding comes from the US government and
work I publish under that funding must be exempt from copyright (i.e.
public domain). Is this then incompatible with the fsf copyright
assignment, and hence mean I cannot make contributions to such GNU
software on time I spend as part of that funding, even if I might
consider it part of my research?

Re: On Contributing To Emacs

[Eli Zaretskii]

> From: Akira Kyle <akira@akirakyle.com>
> Date: Wed, 29 Dec 2021 17:15:17 -0700
> Cc: Richard Stallman <rms@gnu.org>, Emacs developers <emacs-devel@gnu.org>
> 
> It is really a shame that this process is so time consuming and
> discouraging for someone like me.

The word "shame" doesn't belong here IMO, or at least it isn't the
copyright assignment process that should be ashamed.  Blame the
ridiculous software copyright issues and large corporations that are
behind those, and also dishonest people and companies which use free
software without making their code freely available.

Saying "it's a shame" that assignment process is needed and is in some
cases legally complicated is like blaming the traffic lights for
turning red at times.  It's not the traffic light that should be
blamed, it's the chaos that would ensue if the traffic laws were not
in place and enforced.

Of course, speeding up the assignment process is a worthy goal, but
some things cannot be sped up beyond some limit, and if people and
organizations should be involved that are not the FSF staff, we cannot
in good faith blame the FSF staff for having to wait for those other
people to get their act together.

In general, my advice to people who send the assignment form is to
ping the FSF clerk after a week if they don't get any response and CC
me.

Re: On Contributing To Emacs

[xenodasein--- via Emacs development discussions.]

Dec 30, 2021, 09:29 by eliz@gnu.org:

> The word "shame" doesn't belong here IMO, or at least it isn't the
> copyright assignment process that should be ashamed.  Blame the
> ridiculous software copyright issues and large corporations that are
> behind those, and also dishonest people and companies which use free
> software without making their code freely available.
>
> Saying "it's a shame" that assignment process is needed and is in some
> cases legally complicated is like blaming the traffic lights for
> turning red at times.  It's not the traffic light that should be
> blamed, it's the chaos that would ensue if the traffic laws were not
> in place and enforced.
>
> Of course, speeding up the assignment process is a worthy goal, but
> some things cannot be sped up beyond some limit, and if people and
> organizations should be involved that are not the FSF staff, we cannot
> in good faith blame the FSF staff for having to wait for those other
> people to get their act together.
>
> In general, my advice to people who send the assignment form is to
> ping the FSF clerk after a week if they don't get any response and CC
> me.
>

+1

Re: On Contributing To Emacs

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>  Blame the
> ridiculous software copyright issues and large corporations that are
> behind those, and also dishonest people and companies which use free
> software without making their code freely available.

FWIW, I fully and completely agree with the general sentiment here.

It is this unjust, immoral and pernicious situation that forces us to
use copy-left to begin with.  In a reasonable system, there would be no
need to use licenses to protect our rights.

> Saying "it's a shame" that assignment process is needed and is in some
> cases legally complicated is like blaming the traffic lights for
> turning red at times.  It's not the traffic light that should be
> blamed, it's the chaos that would ensue if the traffic laws were not
> in place and enforced.

The copyright assignment requirement is not forced on us by external
factors.  With few exceptions, the rest of the free software world lives
happily without it.  Emacs *choose* to use it in the hope that it will
give some legal advantages in a future GPL violation case.

Whether or not that will be needed in such a trial is anybody's guess
(including the FSF lawyers, BTW, so they keep insisting) but I note that
there are several GPL violation cases that have been quite successful
without it.

Glibc and GCC have recently moved to use a DCO instead.  I think we
should follow their lead:

https://sourceware.org/glibc/wiki/Contribution%20checklist#Copyright_and_license

Re: On Contributing To Emacs

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> The copyright assignment requirement is not forced on us by external
> factors.  With few exceptions, the rest of the free software world
> lives happily without it.  Emacs *choose* to use it in the hope that
> it will give some legal advantages in a future GPL violation case.

IIRC, Emacs did not make that choice arbitrarily, but under the advice
of legal professionals hired by the FSF.

> Whether or not that will be needed in such a trial is anybody's guess
> (including the FSF lawyers, BTW, so they keep insisting) but I note
> that there are several GPL violation cases that have been quite
> successful without it.
>
> Glibc and GCC have recently moved to use a DCO instead.  I think we
> should follow their lead.

You and I are not lawyers, so I don't think we're qualified to make
statements against those of trained professionals.

But I'm going to say that from anecdotal experience that informal
assignments of copyright and "certificates of origin" don't hold much
water in court (not even Chinese court, which doesn't usually care about
the issue in general.)

In fact, this specific issue is why the lawyers at my shop are holding
back the upgrade from GCC 7.5 to 12 when it is released, which doesn't
make sense to me, but there is probably a reason they are doing this.

Re: On Contributing To Emacs

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> You and I are not lawyers, so I don't think we're qualified to make
> statements against those of trained professionals.

I think that this oft-repeated argument is based on some important
misunderstandings.  We will do well to listen to what trained
professionals think about the legal aspects of this, of course.

But first, I think it is important to note that this is *not* clear-cut.
Siddhesh Poyarekar made this point on the Glibc mailing list this
summer:

    Lawyers are not a collective, IP lawyers, less so.  I have spoken to
    and listened to multiple legal experts over the years to get their
    opinion on the subject and in my experience the opinion is quite
    divided and definitely more nuanced than A > B.  I made that
    conclusion for myself based on those opinions.

    https://sourceware.org/pipermail/libc-alpha/2021-June/128083.html

Second, it is also important to note that lawyers have no formal
expertise in how free software projects work or should best be managed.
They have no expertise in assessing the significant drawbacks that this
brings to a free software project, and how that should be weighed
against the legal advantages they perceive (or not) with having a
copyright assignment.

See here for more:

    https://sfconservancy.org/blog/2014/jun/09/do-not-need-cla/

Re: On Contributing To Emacs

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> But first, I think it is important to note that this is *not* clear-cut.
> Siddhesh Poyarekar made this point on the Glibc mailing list this
> summer:

To the FSF it seems to be clear cut, because they are relying on the
advice of their lawyers to hold up in court.  So I don't think we are
going to do much to change their minds.

> Second, it is also important to note that lawyers have no formal
> expertise in how free software projects work or should best be
> managed.  They have no expertise in assessing the significant
> drawbacks that this brings to a free software project, and how that
> should be weighed against the legal advantages they perceive (or not)
> with having a copyright assignment.

How many drawbacks a free software project might get is moot, if it's
not (or can't be kept) legally free software.  We should not let some
vague definition of "drawback" or "weight" interfere.

Re: On Contributing To Emacs

[Tim Cross]

Po Lu <luangruo@yahoo.com> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> But first, I think it is important to note that this is *not* clear-cut.
>> Siddhesh Poyarekar made this point on the Glibc mailing list this
>> summer:
>
> To the FSF it seems to be clear cut, because they are relying on the
> advice of their lawyers to hold up in court.  So I don't think we are
> going to do much to change their minds.
>
>> Second, it is also important to note that lawyers have no formal
>> expertise in how free software projects work or should best be
>> managed.  They have no expertise in assessing the significant
>> drawbacks that this brings to a free software project, and how that
>> should be weighed against the legal advantages they perceive (or not)
>> with having a copyright assignment.
>
> How many drawbacks a free software project might get is moot, if it's
> not (or can't be kept) legally free software.  We should not let some
> vague definition of "drawback" or "weight" interfere.

Agree.

In the same way that lawyers don't have formal experience in how free
software projects work, developers don't have formal experience in how
the legal system and courts work. It is illogical to try and argue that
because lawyers don't understand software projects, we should ignore
their advice on legal matters. We should ignore development/coding
advice from lawyers and ignore legal advice from developers and coders!

In fact, I would go so far as to say many developers make very poor
lawyers. Writing code has a lot to do with conciseness, well defined
logic and unambiguous 'laws'. The legal system and courts are very
different. Much comes down to persuasive arguments from experienced
lawyers, legal precedence, background and perceptions of decision makers
(juries, judges, etc) and even current political and social 'norms' at
the time as well as the ability of those involved to understand the
complexities of the issues (which is often very limited, especially when
it comes to fast moving areas of technology).

Re: On Contributing To Emacs

[Tim Cross]

dick <dick.r.chiang@gmail.com> writes:

> TC> In fact, I would go so far as to say many developers make very poor
> TC> lawyers.
>
> Well, which is it?  You disclaim legal know-how while simultaneously
> claiming to know what it takes to be a lawyer.
>

TO keep it simple, legal advice from developers is worth about as much
as programming advice from lawyers. Any arguments from developers on
this list regarding how the FSF should or should not manage the legal
question of copyright are pointless. I also agree with ELi and think
this topic should be redirected to the tangents list as well, so won't
respond further.

Re: On Contributing To Emacs

[Po Lu]

Tim Cross <theophilusx@gmail.com> writes:

> To keep it simple, legal advice from developers is worth about as much
> as programming advice from lawyers. Any arguments from developers on
> this list regarding how the FSF should or should not manage the legal
> question of copyright are pointless. I also agree with ELi and think
> this topic should be redirected to the tangents list as well, so won't
> respond further.

You might want to know that Dick Chiang has been banned from
emacs-devel, and it would be a good idea to not engage his provocations.

Re: On Contributing To Emacs

[Po Lu]

Tim Cross <theophilusx@gmail.com> writes:

> In the same way that lawyers don't have formal experience in how free
> software projects work, developers don't have formal experience in how
> the legal system and courts work. It is illogical to try and argue that
> because lawyers don't understand software projects, we should ignore
> their advice on legal matters. We should ignore development/coding
> advice from lawyers and ignore legal advice from developers and coders!

I agree, though on a slight tangent, some lawyers are also pretty good
programmers :)

Re: On Contributing To Emacs

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Thu, 30 Dec 2021 06:20:03 -0500
> Cc: Eli Zaretskii <eliz@gnu.org>, Akira Kyle <akira@akirakyle.com>, larsi@gnus.org, rms@gnu.org, 
> 	emacs-devel@gnu.org
> 
> But first, I think it is important to note that this is *not* clear-cut.
> Siddhesh Poyarekar made this point on the Glibc mailing list this
> summer:

Siddhesh's is just one opinion.  Others expressed different views in
that discussion, including some who described real problems and
dangers with the DCO.  That some prefer to ignore those dangers
doesn't mean reasonable people who value the GNU project should do the
same.

Re: On Contributing To Emacs

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

The Glibc and GCC developers made a bad decision last June.  The DCO
they are using is full of gaps, and they don't get it from all the
authors.  A copyright assignment is much better.

I'm working on better DCO which is intended to correct some of its
problems.  However, it will still be second best.  We will continue to
get copyright assignments, not DCOs.

In addition to the copyright assignment (or substitute), we ask for
employers' disclaimers.  They do a different job, which is
complementary to the job that an assignment does (and a DCO tries to
do).

Thus, using a DCO instead of an assignment does not make the process
much easier or faster, unless the project does it carelessly.

I ask lawyers how to keep the the copyleft strong, because that is
a priority for the free software movement.  I don't ask them whether
that should be our priority, because that's the starting point.

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

Re: On Contributing To Emacs

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> The copyright assignment requirement is not forced on us by external
>> factors.  With few exceptions, the rest of the free software world
>> lives happily without it.  Emacs *choose* to use it in the hope that
>> it will give some legal advantages in a future GPL violation case.
>
> IIRC, Emacs did not make that choice arbitrarily, but under the advice
> of legal professionals hired by the FSF.

You are assuming that those lawyers said "You shall definitely do this"
and the FSF followed suit, but we don't know the internal process of
that decision. Possibly the lawyers said "you could do A or B or C, and
we estimate that the risks and benefits are such and such" and then the
FSF chose the option that best suited them. Or it could be that the FSF
said to the lawyers "we want maximum protection" (leaving other factors
aside) and the lawyers complied.

>> Glibc and GCC have recently moved to use a DCO instead.  I think we
>> should follow their lead.
>
> You and I are not lawyers, so I don't think we're qualified to make
> statements against those of trained professionals.

Again, you are assuming things, namely, that the decision about using
the DCO was not backed by lawyers.

Re: On Contributing To Emacs

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Thu, 30 Dec 2021 05:27:31 -0500
> Cc: larsi@gnus.org, rms@gnu.org, emacs-devel@gnu.org
> 
> > Saying "it's a shame" that assignment process is needed and is in some
> > cases legally complicated is like blaming the traffic lights for
> > turning red at times.  It's not the traffic light that should be
> > blamed, it's the chaos that would ensue if the traffic laws were not
> > in place and enforced.
> 
> The copyright assignment requirement is not forced on us by external
> factors.  With few exceptions, the rest of the free software world lives
> happily without it.  Emacs *choose* to use it in the hope that it will
> give some legal advantages in a future GPL violation case.
> 
> Whether or not that will be needed in such a trial is anybody's guess
> (including the FSF lawyers, BTW, so they keep insisting) but I note that
> there are several GPL violation cases that have been quite successful
> without it.
> 
> Glibc and GCC have recently moved to use a DCO instead.  I think we
> should follow their lead:
> 
> https://sourceware.org/glibc/wiki/Contribution%20checklist#Copyright_and_license

This is a horse that has been beaten to death.  The problems with the
DCO are well-known and documented.  The projects that switched to it
are gambling their future on what they believe is "good enough"
without any proof, like a driver that crosses on red light because he
sees no other vehicle coming.

This is a tangent, so please continue discussing it on emacs-tangents,
not here.

Re: On Contributing To Emacs

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> This is a horse that has been beaten to death.  The problems with the
> DCO are well-known and documented.  The projects that switched to it
> are gambling their future on what they believe is "good enough"
> without any proof,

I hope you are incorrect, otherwise free software as a whole is lost,
especially those projects that do not even have a DCO (which I would
advocate for).

>  like a driver that crosses on red light because he
> sees no other vehicle coming.

I think this significantly exaggerates the problems with using a DCO.

> This is a tangent, so please continue discussing it on emacs-tangents,
> not here.

Let's not side-track the discussion it by turning it into a
meta discussion about where it should be held.  I posted to emacs-devel,
and it is fine if any replies are sent here as well.

Re: On Contributing To Emacs

[Rudolf Adamkovič]

Stefan Kangas <stefankangas@gmail.com> writes:

> The copyright assignment […]

Random idea: Perhaps Emacs could provide a user-friendly command, say
"request-copyright-assignment".  It would explain the need for the
assignments, gather the necessary information from the user, validate
the input, and then send the request to the correct person at FSF.

Rudy
-- 
"'Contrariwise,' continued Tweedledee, 'if it was so, it might be; and
if it were so, it would be; but as it isn't, it ain't. That's logic.'"
-- Lewis Carroll, Through the Looking Glass

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: On Contributing To Emacs

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

  > Random idea: Perhaps Emacs could provide a user-friendly command, say
  > "request-copyright-assignment".  It would explain the need for the
  > assignments, gather the necessary information from the user, validate
  > the input, and then send the request to the correct person at FSF.

If it is mean to be equivalent to filling in the usual form
and eailing that to the FSF, this would be easy and I think there's
no reason not to do it.  Would people find it helpful?

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

Re: On Contributing To Emacs

[Akira Kyle]

On Wed, Dec 29, 2021 at 11:30 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > It is really a shame that this process is so time consuming and
> > discouraging for someone like me.
>
> The word "shame" doesn't belong here IMO, or at least it isn't the
> copyright assignment process that should be ashamed.  Blame the
> ridiculous software copyright issues and large corporations that are
> behind those, and also dishonest people and companies which use free
> software without making their code freely available.
>

I understand the motivation and the worries. Personally I put more
blame on the laws as they exist, and I support advocacy and lobbying
work for improving protections for free software. I just wanted to
voice my personal experience to this list since I assume most people
here have gone through this process years ago and so it may not be so
apparent that this process does present a non-insignificant barrier to
contribution.

As laws, legal precedent, and software practices are very much not
static, it seems like projects that have assignment processes should
periodically reevaluate whether those processes still serve the best
interests of the project. As Stefan Kangas pointed out, GCC recently
reevaluated their process and decided that it would be in their best
interest to change it. Based on the initial reactions to my original
mail, it seems emacs is not ready to even make such a reevaluation.
Sorry for the additional noise this caused, I just thought it would be
important to voice my frustrations here so that the viewpoint from
someone trying to become a newer contributor is heard. My impression
is that such viewpoints are underrepresented on this list.

Re: On Contributing To Emacs

[Theodor Thornhill]

Akira Kyle <akira@akirakyle.com> writes:

> On Wed, Dec 29, 2021 at 11:30 PM Eli Zaretskii <eliz@gnu.org> wrote:
>>
>> > It is really a shame that this process is so time consuming and
>> > discouraging for someone like me.
>>
>> The word "shame" doesn't belong here IMO, or at least it isn't the
>> copyright assignment process that should be ashamed.  Blame the
>> ridiculous software copyright issues and large corporations that are
>> behind those, and also dishonest people and companies which use free
>> software without making their code freely available.
>>

[...]

> Sorry for the additional noise this caused, I just thought it would be
> important to voice my frustrations here so that the viewpoint from
> someone trying to become a newer contributor is heard. My impression
> is that such viewpoints are underrepresented on this list.

Agreed.  I don't see it as insignificant either.  In my experience, my
employers have been accomodating, but always confused, as none of them
ever received such a request.  They view it as a hassle, and usually
have delayed it for a long time.  I even had to go several rounds with
the clerk in some minor issue that required the ceo of $employer to read
and sign things multiple times.  Surely that was my fault, but still
embarassing and aggravating.

One other thing noone seems to mention is that when you change jobs, you
have to do it all over again.  Having to go over this in a new job while
trying to settle in socially and professionally is suboptimal.  I'm
lucky my latest employer has no such "we own your free time as well as
work time" clause, so I don't have to do all over again.

I also don't view this as tangential to emacs development, as this is a
major hurdle for many people to contribute.

Just my two cents.

Theo

Re: On Contributing To Emacs

[Po Lu]

Theodor Thornhill <theo@thornhill.no> writes:

> One other thing noone seems to mention is that when you change jobs, you
> have to do it all over again.  Having to go over this in a new job while
> trying to settle in socially and professionally is suboptimal.  I'm
> lucky my latest employer has no such "we own your free time as well as
> work time" clause, so I don't have to do all over again.
>
> I also don't view this as tangential to emacs development, as this is a
> major hurdle for many people to contribute.

My employer has rules on checking the "ownership" of free software
projects employees contribute to.  With Emacs, the parts not under FSF
copyright are either under the copyright of the Japanese government
(MULE), or too insignificant to matter, which makes that process simple.

If the copyright status were to become any more complicated, then we
would have to go through months of paperwork before doing any work on
Emacs (or more importantly, GCC, which we work on during the day.)

This is a major problem with X, especially since the headers regularly
mention defunct organizations whose "assets" are troublesome to track
down.

Re: On Contributing To Emacs

[Eli Zaretskii]

> From: Theodor Thornhill <theo@thornhill.no>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Richard Stallman <rms@gnu.org>,
>  Emacs developers <emacs-devel@gnu.org>
> Date: Thu, 30 Dec 2021 22:01:15 +0100
> 
> One other thing noone seems to mention is that when you change jobs, you
> have to do it all over again.

It's mentioned frequently enough, don't worry.

What's also mentioned is that you could negotiate a contract which
says software you write on your free time is not the property of the
employer, at least under some reasonable conditions, and then you
don't need to ask them for any legal paperwork when you contribute to
Emacs.  And before you say that this is only a theoretical
possibility: I'm one person with such a contract (well, was, before I
retired).

Re: On Contributing To Emacs

[Eli Zaretskii]

> From: Akira Kyle <akira@akirakyle.com>
> Date: Thu, 30 Dec 2021 13:17:27 -0700
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Richard Stallman <rms@gnu.org>, Emacs developers <emacs-devel@gnu.org>
> 
> Based on the initial reactions to my original mail, it seems emacs
> is not ready to even make such a reevaluation.

That'd be one interpretation of what you read, but it isn't the only
one.  Nor is it the most friendly one, frankly.

The truth is that we reevaluate this as much as other projects do (how
else would a reasonable person react when he or she reads the
discussions like those that happened recently on GCC and glibc
lists?), we just conclude that the policy should not change, because
the alternatives propose for the copyright assignment are worse than
what we have.

Re: On Contributing To Emacs

[Akira Kyle]

On Fri, Dec 31, 2021 at 12:17 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > Based on the initial reactions to my original mail, it seems emacs
> > is not ready to even make such a reevaluation.
>
> That'd be one interpretation of what you read, but it isn't the only
> one.  Nor is it the most friendly one, frankly.
>

Sorry for my initial uncharitable view of how emacs-devel thinks about this.

> The truth is that we reevaluate this as much as other projects do (how
> else would a reasonable person react when he or she reads the
> discussions like those that happened recently on GCC and glibc
> lists?), we just conclude that the policy should not change, because
> the alternatives propose for the copyright assignment are worse than
> what we have.

I was not aware that GCC had even changed its process until this email
thread. The little bit I've read so far about that change does make me
better understand the attitudes people have here towards the topic. I
do hope there may still be ways of improving the current process emacs
uses for assigments.

Re: On Contributing To Emacs

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

  > Indeed. Speaking from my own experience, I've been putting off getting
  > my assignment done because apparently, as a university student, I need
  > to do extra work and find the right person at my school to also sign
  > off on this.

I was talking about the copyright assignment, but you're talking about
the employer copyright disclaimer.  They are needed for the same
situation, but in the specifics they are completely different.

The speed of processing assignments is a matter of how fast the FSF
staff do that job.  A couple of years ago, we made that much faster
and more reliable.

Obtaining the employer disclaimer is between you and your employer.
The FSF staff have no way to speed that up; they can't do it for you.

The employer disclaimer has nothing to do with being a student at a
university.  In the US, a university cannot claim copyright on a
student's writings just because perse is a student.  If the work is
for a class, or a private project, the university has no claim, unless
perse substantially uses some special facilities to do it.  (Not just
the internet, printers, ordinary student computing, and email
accounts.)  The university will give you a booklet describing this
policy.

The case where a university does have a claim is when the student is
also an employee and the work is part of per _job_.  Then it's like
any other employment.  We need to know that per employer does not make
a legal claim to that work.

That applies to you because (from what you said) you have a research
job and the work you're doing on Emacs might be considered part of it.

But the university doesn't have to considered it part of that job.
What we do is ask the university to affirm that it does not consider
your changes to Emacs to be work done for your job.

Normally, the person you should discuss this with is your supervisor.
A supervisor is supposed to know how to do this.  If yours doesn't
know, perse will at least know which office to ask.  (It may be the
"technology licensing office" or (yuck!) "intellectual property
office" (see https://gnu.org/philosophy/not-ipr.html).)  If you show
per the form the FSF staff send you, you could get this going next
week.

You can ask the FSF staff for advice about how to go about this, but I
expect they will tell you the same thing I said here.

If the university objects, then you should show the FSF staff the
response you got.  At that point, they can help work something out
with the university.  But this only rarely happens, so don't worry
about it now.

  > I also have a question that I might as well ask here in case anyone
  > knows the answer: part of my funding comes from the US government and
  > work I publish under that funding must be exempt from copyright (i.e.
  > public domain). Is this then incompatible with the fsf copyright
  > assignment,

Indeed, that is an issue.  You can't assign the copyright if you don't
have the copyright.  (That's also the reason we need employer
disclaimers.)

                and hence mean I cannot make contributions to such GNU
  > software on time I spend as part of that funding, 

It's not a problem at all.  Instead of an assignment, you can sign
something different affirming that this work is in the public domain.
It's an unusual thing to do, but not difficult.  The FSF staff can
help you out.

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

Re: On Contributing To Emacs

[Akira Kyle]

On Thu, Dec 30, 2021 at 2:23 PM Richard Stallman <rms@gnu.org> wrote:
>
> I was talking about the copyright assignment, but you're talking about
> the employer copyright disclaimer.  They are needed for the same
> situation, but in the specifics they are completely different.
>

Sorry I wasn't specific in my language. I was not aware there was also
this employer copyright disclaimer until I received the email from
assign@gnu.org.

> The speed of processing assignments is a matter of how fast the FSF
> staff do that job.  A couple of years ago, we made that much faster
> and more reliable.
>
> Obtaining the employer disclaimer is between you and your employer.
> The FSF staff have no way to speed that up; they can't do it for you.
>
> The employer disclaimer has nothing to do with being a student at a
> university.  In the US, a university cannot claim copyright on a
> student's writings just because perse is a student.  If the work is
> for a class, or a private project, the university has no claim, unless
> perse substantially uses some special facilities to do it.  (Not just
> the internet, printers, ordinary student computing, and email
> accounts.)  The university will give you a booklet describing this
> policy.
>
> The case where a university does have a claim is when the student is
> also an employee and the work is part of per _job_.  Then it's like
> any other employment.  We need to know that per employer does not make
> a legal claim to that work.
>
> That applies to you because (from what you said) you have a research
> job and the work you're doing on Emacs might be considered part of it.
>
> But the university doesn't have to considered it part of that job.
> What we do is ask the university to affirm that it does not consider
> your changes to Emacs to be work done for your job.
>
> Normally, the person you should discuss this with is your supervisor.
> A supervisor is supposed to know how to do this.  If yours doesn't
> know, perse will at least know which office to ask.  (It may be the
> "technology licensing office" or (yuck!) "intellectual property
> office" (see https://gnu.org/philosophy/not-ipr.html).)  If you show
> per the form the FSF staff send you, you could get this going next
> week.
>
> You can ask the FSF staff for advice about how to go about this, but I
> expect they will tell you the same thing I said here.
>
> If the university objects, then you should show the FSF staff the
> response you got.  At that point, they can help work something out
> with the university.  But this only rarely happens, so don't worry
> about it now.
>

I wish this process was more transparent than "send an email to
assign@gnu.org and wait for a response". Why can't there be some
webpage that outlines the process along with the necessary forms that
I can follow and collect then send to assign@gnu.org? Such a page
could then link to resources from experts which explain the issues
(for example I find this recent piece quite compelling:
https://sfconservancy.org/blog/2021/jun/30/who-should-own-foss-copyrights/)
and offer a FAQ. Such resources exist but I, as a relatively
uninformed newcomer to such issues, have to find them myself, adding
to the feeling that the process is burdensome.

I'm not trying to argue the underlying issues aren't important here,
just that the transparency and "user experience" are very much
lacking. Given the importance of assignments to emacs, perhaps there
should be some more substantial text stating the reasoning specific to
emacs as to why the project feels it is the right course (as opposed
to say guix which does not require assignments). Without such clarity
for the justifications, and the steps to take, the process feels more
burdensome.

>   > I also have a question that I might as well ask here in case anyone
>   > knows the answer: part of my funding comes from the US government and
>   > work I publish under that funding must be exempt from copyright (i.e.
>   > public domain). Is this then incompatible with the fsf copyright
>   > assignment,
>
> Indeed, that is an issue.  You can't assign the copyright if you don't
> have the copyright.  (That's also the reason we need employer
> disclaimers.)
>
>                 and hence mean I cannot make contributions to such GNU
>   > software on time I spend as part of that funding,
>
> It's not a problem at all.  Instead of an assignment, you can sign
> something different affirming that this work is in the public domain.
> It's an unusual thing to do, but not difficult.  The FSF staff can
> help you out.
>

Okay thanks.

Re: On Contributing To Emacs

[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 wish this process was more transparent than "send an email to
  > assign@gnu.org and wait for a response". Why can't there be some
  > webpage that outlines the process along with the necessary forms that
  > I can follow and collect then send to assign@gnu.org?

The instructions would have to be complex and state various if-then's.
Interpreting them would take time and thought, and would be
unreliable.

So we decided that our staff should ask the contributor for the
pertinent facts and then tell per what papers to use.  It is faster
and less work for the contributor, and less likely to lead to errors.

Just in case this might have changed in the past few years, I am
asking the staff to verify this.

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

Re: On Contributing To Emacs

[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 wish this process was more transparent than "send an email to
  > assign@gnu.org and wait for a response". Why can't there be some
  > webpage that outlines the process along with the necessary forms that
  > I can follow and collect then send to assign@gnu.org?

The instructions are complex, and depend on circumstances.  We can
send them to a contributor who wants to know all the options we can
handle; but having each contributor figure out what to do would be a
lot more work for each, and would be unreliable.

So the easy way is to let the FSF staff ask the contributor for the
pertinent facts, then recommend what papers to use.  It is faster and
less work for the contributor, and less likely to lead to errors.
Please do not try to figure out on your own how to do that -- discuss
it with the staff.

Just in case this might have changed in the past few years, I asked
the staff to verify it still works that way.

  > Such resources exist but I, as a relatively
  > uninformed newcomer to such issues, have to find them myself,

You don't need those resources to submit FSF copyright papers.  I will
look at the page you mentioned, but I doubt that SFC is trying to
explain how to do that.

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

Re: On Contributing To Emacs

[Akira Kyle]

On Thu, Dec 30, 2021 at 9:27 PM Richard Stallman <rms@gnu.org> wrote:
>
>   > I wish this process was more transparent than "send an email to
>   > assign@gnu.org and wait for a response". Why can't there be some
>   > webpage that outlines the process along with the necessary forms that
>   > I can follow and collect then send to assign@gnu.org?
>
> The instructions are complex, and depend on circumstances.  We can
> send them to a contributor who wants to know all the options we can
> handle; but having each contributor figure out what to do would be a
> lot more work for each, and would be unreliable.
>
> So the easy way is to let the FSF staff ask the contributor for the
> pertinent facts, then recommend what papers to use.  It is faster and
> less work for the contributor, and less likely to lead to errors.
> Please do not try to figure out on your own how to do that -- discuss
> it with the staff.
>
> Just in case this might have changed in the past few years, I asked
> the staff to verify it still works that way.
>

Okay thanks for explaining why the current process exists in the way
it does. I don't think this is the process described in CONTRIBUTE
though where it instructs one to download the form and fill it out,
then send it. Perhaps this could be summed up in a sentence and added
to CONTRIBUTE so someone understands why emailing assign@gnu.org is
the first step and this multi-step process? It may also help to be
upfront in CONTRIBUTE that this process can often take time so that
expectations are correctly set at the outset. That might help
alleviate some of the perceived difficulty of this process.

>   > Such resources exist but I, as a relatively
>   > uninformed newcomer to such issues, have to find them myself,
>
> You don't need those resources to submit FSF copyright papers.  I will
> look at the page you mentioned, but I doubt that SFC is trying to
> explain how to do that.
>

I know I don't need those resources to actually complete the
assignment, and I'm sure there are many contributors who just want to
get the process over with and don't care about the justifications.
However I think there are also contributors who, like me, are curious
as to why the process exists in the form it does. At least for me,
reading about the reasons for copyright assignments and understanding
the justifications behind them with examples of copyright violation
cases where copyright assignments has made a difference has been very
important in shaping my perception of the burden of the process.
Without such an understanding, I think it is much easier for a new
contributor to see only the burden, be frustrated at the process, and
even think it's entirely unnecessary. With such an understanding of
the important reasons, it feels less burdensome and is easier to
accept why it is a necessary prerequisite of contributing. This is why
I would suggest the initial email from assign@gnu.org include more
links to articles explaining these justifications, preferably from
legal or other experts on the topic, so that a curious new contributor
like me may educate themselves first, before sending an email, like I
did earlier to this list.

Re: On Contributing To Emacs

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

  > Okay thanks for explaining why the current process exists in the way
  > it does. I don't think this is the process described in CONTRIBUTE
  > though where it instructs one to download the form and fill it out,
  > then send it.

Yes, it is the same.  You send in the basic information and the FSF
staff take it from there.

  > However I think there are also contributors who, like me, are curious
  > as to why the process exists in the form it does.

There is some information the reasons for our approach in
https://gnu.org/licenses/.


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

Re: On Contributing To Emacs

[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 saying that as if having a two week turnaround is an achievement
  > instead of the failure that it is.

It works well enough.  Most contributors don't mind a short wait,
since they only have to wait once.


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

Re: On Contributing To Emacs

[Stefan Kangas]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> - Development velocity is glacial. With releases around once per year
> and there being no easily accessible distribution mechanism for
> development updates,

Our core packages can be released straight from master to GNU ELPA
within 24 hours.  All you need to do, once it is set up (which in itself
is trivial), is to bump the version header.  This is already the case
with for example flymake.el and python.el.

So while I agree that it would be good if Emacs could release major
versions more often (we currently release every two years, AFAICT),
I don't think this stops packages developed directly on master from
following a much more frequent release schedule.

Re: On Contributing To Emacs

[Ihor Radchenko]

Stefan Kangas <stefankangas@gmail.com> writes:

> Our core packages can be released straight from master to GNU ELPA
> within 24 hours.  All you need to do, once it is set up (which in itself
> is trivial), is to bump the version header.  This is already the case
> with for example flymake.el and python.el.

Could this information be added to "GNU ELPA" section of the CONTRIBUTE
file? The current contents of the section is rather confusing:

"This repository does not contain the Emacs Lisp package archive
(elpa.gnu.org).  See admin/notes/elpa for how to access the GNU ELPA
repository."

Best,
Ihor

Re: On Contributing To Emacs

[Stefan Kangas]

Ihor Radchenko <yantar92@gmail.com> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> Our core packages can be released straight from master to GNU ELPA
>> within 24 hours.  All you need to do, once it is set up (which in itself
>> is trivial), is to bump the version header.  This is already the case
>> with for example flymake.el and python.el.
>
> Could this information be added to "GNU ELPA" section of the CONTRIBUTE
> file? The current contents of the section is rather confusing:
>
> "This repository does not contain the Emacs Lisp package archive
> (elpa.gnu.org).  See admin/notes/elpa for how to access the GNU ELPA
> repository."

How is this?

diff --git a/CONTRIBUTE b/CONTRIBUTE
index 7c3421ed75..f2d161e808 100644
--- a/CONTRIBUTE
+++ b/CONTRIBUTE
@@ -372,6 +372,14 @@ This repository does not contain the Emacs Lisp
package archive
 (elpa.gnu.org).  See admin/notes/elpa for how to access the GNU ELPA
 repository.

+Some packages are so-called "core" packages.  The GNU ELPA scripts
+will pick them up from the Emacs master branch and release them as
+packages periodically; a new version is packaged when their "Version"
+comment header is updated.  Normally a new package is released within
+24 hours after bumping the version on the Emacs master branch.  An
+examples is lisp/progmodes/python.el, which is released as the "python"
+package at: https://elpa.gnu.org/packages/python.html
+
 ** Understanding Emacs internals

 The best way to understand Emacs internals is to read the code.  Some

Re: On Contributing To Emacs

[Ihor Radchenko]

Stefan Kangas <stefankangas@gmail.com> writes:

>> Could this information be added to "GNU ELPA" section of the CONTRIBUTE
>> file? The current contents of the section is rather confusing:
>>
>> "This repository does not contain the Emacs Lisp package archive
>> (elpa.gnu.org).  See admin/notes/elpa for how to access the GNU ELPA
>> repository."
>
> How is this?
>
> diff --git a/CONTRIBUTE b/CONTRIBUTE
> index 7c3421ed75..f2d161e808 100644
> --- a/CONTRIBUTE
> +++ b/CONTRIBUTE
> @@ -372,6 +372,14 @@ This repository does not contain the Emacs Lisp
> package archive
>  (elpa.gnu.org).  See admin/notes/elpa for how to access the GNU ELPA
>  repository.
>
> +Some packages are so-called "core" packages.  The GNU ELPA scripts
> +will pick them up from the Emacs master branch and release them as
> +packages periodically; a new version is packaged when their "Version"
> +comment header is updated.  Normally a new package is released within
> +24 hours after bumping the version on the Emacs master branch.  An
> +examples is lisp/progmodes/python.el, which is released as the "python"
> +package at: https://elpa.gnu.org/packages/python.html

I do not see this on my side:
https://git.savannah.gnu.org/cgit/emacs.git/tree/CONTRIBUTE#n369

Best,
Ihor

Re: On Contributing To Emacs

[Stefan Kangas]

Ihor Radchenko <yantar92@gmail.com> writes:

> I do not see this on my side:
> https://git.savannah.gnu.org/cgit/emacs.git/tree/CONTRIBUTE#n369

Sorry if I wasn't clear: this is just a patch for now.
I didn't yet push it.

Re: On Contributing To Emacs

[Ihor Radchenko]

Stefan Kangas <stefankangas@gmail.com> writes:

> Sorry if I wasn't clear: this is just a patch for now.
> I didn't yet push it.

Got it. I misunderstood the meaning of "how is this?" (treating it as if
you pointed to an already existing change).

> +Some packages are so-called "core" packages.  The GNU ELPA scripts
> +will pick them up from the Emacs master branch and release them as
> +packages periodically; a new version is packaged when their "Version"
> +comment header is updated.  Normally a new package is released within
> +24 hours after bumping the version on the Emacs master branch.  An
> +examples is lisp/progmodes/python.el, which is released as the "python"
> +package at: https://elpa.gnu.org/packages/python.html

Still sounds confusing. Ideally, I would like to see a separate heading,
immediately visible by contributors. Something like "Releasing updates
in Emacs core ahead of next Emacs version", but probably more succinct.

> +Some packages are so-called "core" packages.

Maybe, "GNU ELPA is also used to distribute latest changes in built-in
packages ahead of the next Emacs release."

---

Not directly related to you patch, but rather to the existing text:

>> This repository does _not_ contain the Emacs Lisp package archive
>> (elpa.gnu.org).

This is totally confusing. GNU ELPA does not contain packages? tarballs?
What does it contain?

Best,
Ihor

Re: On Contributing To Emacs

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Wed, 29 Dec 2021 01:33:57 -0800
> Cc: emacs-devel@gnu.org
> 
> >> Our core packages can be released straight from master to GNU ELPA
> >> within 24 hours.  All you need to do, once it is set up (which in itself
> >> is trivial), is to bump the version header.  This is already the case
> >> with for example flymake.el and python.el.
> >
> > Could this information be added to "GNU ELPA" section of the CONTRIBUTE
> > file? The current contents of the section is rather confusing:
> >
> > "This repository does not contain the Emacs Lisp package archive
> > (elpa.gnu.org).  See admin/notes/elpa for how to access the GNU ELPA
> > repository."
> 
> How is this?
> 
> diff --git a/CONTRIBUTE b/CONTRIBUTE
> index 7c3421ed75..f2d161e808 100644
> --- a/CONTRIBUTE
> +++ b/CONTRIBUTE
> @@ -372,6 +372,14 @@ This repository does not contain the Emacs Lisp
> package archive
>  (elpa.gnu.org).  See admin/notes/elpa for how to access the GNU ELPA
>  repository.
> 
> +Some packages are so-called "core" packages.  The GNU ELPA scripts
> +will pick them up from the Emacs master branch and release them as
> +packages periodically; a new version is packaged when their "Version"
> +comment header is updated.  Normally a new package is released within
> +24 hours after bumping the version on the Emacs master branch.  An
> +examples is lisp/progmodes/python.el, which is released as the "python"
> +package at: https://elpa.gnu.org/packages/python.html
> +

The file CONTRIBUTE is supposed to help contributors, actual and
potential, to understand how to participate in the Emacs project.
That's what it says at its beginning:

  * How developers contribute to GNU Emacs

  Here is how software developers can contribute to Emacs.

I don't see how the above text fits that purpose.  The ELPA section is
there, and says what it says, so that people wouldn't assume that this
file also covers ELPA:

  ** GNU ELPA

  This repository does not contain the Emacs Lisp package archive
  (elpa.gnu.org).  See admin/notes/elpa for how to access the GNU ELPA
  repository.

It is okay to add text about ELPA if it includes some practically
useful information about something related to ELPA that is relevant to
contributing to the Emacs project.  But the proposed text doesn't have
any such practical information, it just expands on what ELPA
provides.  (It also talks about "core" packages without explaining
what that means or how to tell whether a given package is "core".)

So if we want to add something like that to CONTRIBUTE, we need to
rephrase it so that it fits the purpose of this file.  I cannot yet
see how to rephrase that, but that's probably because I don't
understand Ihor's request in the first place: why would it be useful
to have this information in CONTRIBUTE, which is a large file most of
which is utterly irrelevant to ELPA?

Thanks.

Re: On Contributing To Emacs

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

> So if we want to add something like that to CONTRIBUTE, we need to
> rephrase it so that it fits the purpose of this file.  I cannot yet
> see how to rephrase that, but that's probably because I don't
> understand Ihor's request in the first place: why would it be useful
> to have this information in CONTRIBUTE, which is a large file most of
> which is utterly irrelevant to ELPA?

My thinking was as follows:

1. There was a complaint:

>> - Development velocity is glacial. With releases around once per year
>> and there being no easily accessible distribution mechanism for
>> development updates, high-velocity projects or projects that must adapt
>> to a changing ecosystem (straight.el satisfies both of those criteria)
>> simply do not have a place in Emacs core as it exists today.

2. The answer to it was that core packages can be distributed through ELPA
   to provide updates between Emacs releases.

3. I tried to simulate a newcomer aiming to contribute a new built-in
   package to Emacs, but willing to update the contribution frequently.

   I opened CONTRIBUTE file and tried to search useful information with
   the above setup in mind.

4. I did not find anything useful from a first glance (from folded
   headlines)

5. Because someone in the thread pointed that frequent updates in Emacs
   core can be distributed through ELPA, I looked into ELPA section.

6. ELPA section is very confusing with this mindset (and in general as
   well).

   I suggested to improve it by adding information that ELPA can be
   actually used to distribute built-in packages.

   Note that in my last reply to Stefan I also began to think that
   information about built-in package updates should better be described
   in a dedicated section that is visible from the outline.

Best,
Ihor

Re: On Contributing To Emacs

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@gmail.com>
> Cc: Stefan Kangas <stefankangas@gmail.com>,  emacs-devel@gnu.org
> Date: Wed, 29 Dec 2021 21:59:17 +0800
> 
> 1. There was a complaint:
> 
> >> - Development velocity is glacial. With releases around once per year
> >> and there being no easily accessible distribution mechanism for
> >> development updates, high-velocity projects or projects that must adapt
> >> to a changing ecosystem (straight.el satisfies both of those criteria)
> >> simply do not have a place in Emacs core as it exists today.
> 
> 2. The answer to it was that core packages can be distributed through ELPA
>    to provide updates between Emacs releases.
> 
> 3. I tried to simulate a newcomer aiming to contribute a new built-in
>    package to Emacs, but willing to update the contribution frequently.
> 
>    I opened CONTRIBUTE file and tried to search useful information with
>    the above setup in mind.
> 
> 4. I did not find anything useful from a first glance (from folded
>    headlines)

If this is the purpose, we could say something like

  If you would like to contribute a stand-alone package, consider
  submitting it to ELPA, not to Emacs.

Would that be enough?

> 6. ELPA section is very confusing with this mindset (and in general as
>    well).

I find nothing confusing there.  All it says is that the Emacs
repository doesn't include ELPA, which is a separate repository with
its own README file.

IOW, all it wants is to prevent people from mistakenly thinking
CONTRIBUTE and emacs.git in general cover ELPA.

Re: On Contributing To Emacs

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I find nothing confusing there.  All it says is that the Emacs
> repository doesn't include ELPA, which is a separate repository with
> its own README file.

But some packages in Emacs core are also distributed via ELPA, which is
the source of confusion here.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: On Contributing To Emacs

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Ihor Radchenko <yantar92@gmail.com>,  stefankangas@gmail.com,
>   emacs-devel@gnu.org
> Date: Wed, 29 Dec 2021 16:12:09 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I find nothing confusing there.  All it says is that the Emacs
> > repository doesn't include ELPA, which is a separate repository with
> > its own README file.
> 
> But some packages in Emacs core are also distributed via ELPA, which is
> the source of confusion here.

OK, but I still don't see what could we say about that that would help
someone in the context of what CONTRIBUTE is for.  That's why I asked.

On Contributing To Emacs

[Christopher Dimech]

> Sent: Thursday, December 30, 2021 at 5:00 AM
> From: "Eli Zaretskii" <eliz@gnu.org>
> To: "Lars Ingebrigtsen" <larsi@gnus.org>
> Cc: emacs-devel@gnu.org, yantar92@gmail.com, stefankangas@gmail.com
> Subject: Re: On Contributing To Emacs
>
> > From: Lars Ingebrigtsen <larsi@gnus.org>
> > Cc: Ihor Radchenko <yantar92@gmail.com>,  stefankangas@gmail.com,
> >   emacs-devel@gnu.org
> > Date: Wed, 29 Dec 2021 16:12:09 +0100
> >
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> > > I find nothing confusing there.  All it says is that the Emacs
> > > repository doesn't include ELPA, which is a separate repository with
> > > its own README file.
> >
> > But some packages in Emacs core are also distributed via ELPA, which is
> > the source of confusion here.
>
> OK, but I still don't see what could we say about that that would help
> someone in the context of what CONTRIBUTE is for.  That's why I asked.

One can specify precisely, CONTRIBUTE to OFFICIAL EMACS, CONTRIBUTE to ELPA, ...,
with a description of what each means and what each entails.

Re: On Contributing To Emacs

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> But some packages in Emacs core are also distributed via ELPA, which is
>> the source of confusion here.
>
> OK, but I still don't see what could we say about that that would help
> someone in the context of what CONTRIBUTE is for.  That's why I asked.

I think we should say what was in the patch I proposed.  Understanding
what core packages are is useful if you are looking to contribute a new
library, because without such an understanding there is no way to make
an informed the decision about the various ways to integrate your
package into Emacs.

If anyone wants to write a better version of what I wrote, that's fine
by me.

Re: On Contributing To Emacs

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> 3. I tried to simulate a newcomer aiming to contribute a new built-in
>>    package to Emacs, but willing to update the contribution frequently.
>
> If this is the purpose, we could say something like
>
>   If you would like to contribute a stand-alone package, consider
>   submitting it to ELPA, not to Emacs.
>
> Would that be enough?

I don't think so. It's clear how to contribute a stand-alone package.
The confusion comes when someone wants to contribute a built-in package
yet widely available ahead of Emacs next release or in older Emacs.

A real example: RMS recently asked Org ML about splitting Org mode into
modules and integrating them into Emacs code proper. And we do have some
modules that could be integrated into Emacs: recent org-persist was
written with RMS request in mind; upcoming redesign of folding system
will have a universal module for text folding; some parts of Org parser
could be reused in the code (we have incremental parser equivalent to
tree-sitter implemented fully in Elisp).

However, without knowing that built-in Emacs packages can be distributed
via ELPA, the above is difficult to achieve. Org promises to support
older Emacs versions and we cannot rely on all the users using master
version of Emacs (we cannot even rely on latest Emacs release).

>> 6. ELPA section is very confusing with this mindset (and in general as
>>    well).
>
> I find nothing confusing there.  All it says is that the Emacs
> repository doesn't include ELPA, which is a separate repository with
> its own README file.
>
> IOW, all it wants is to prevent people from mistakenly thinking
> CONTRIBUTE and emacs.git in general cover ELPA.

The confusion is for the users who do not know what is GNU ELPA.

Best,
Ihor

Re: On Contributing To Emacs

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@gmail.com>
> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 29 Dec 2021 23:48:57 +0800
> 
> >   If you would like to contribute a stand-alone package, consider
> >   submitting it to ELPA, not to Emacs.
> >
> > Would that be enough?
> 
> I don't think so. It's clear how to contribute a stand-alone package.
> The confusion comes when someone wants to contribute a built-in package
> yet widely available ahead of Emacs next release or in older Emacs.

Then let's tell what should be done in order to contribute such a
package.  If this is already described in the ELPA documentation, it
should be enough to point contributors that are interested in this
there; if ELPA doesn't describe it, perhaps it should, or we could say
something in CONTRIBUTE, assuming it could be said succinctly enough.

But the proposed change didn't do any of that, AFAICT.

> A real example: RMS recently asked Org ML about splitting Org mode into
> modules and integrating them into Emacs code proper. And we do have some
> modules that could be integrated into Emacs: recent org-persist was
> written with RMS request in mind; upcoming redesign of folding system
> will have a universal module for text folding; some parts of Org parser
> could be reused in the code (we have incremental parser equivalent to
> tree-sitter implemented fully in Elisp).
> 
> However, without knowing that built-in Emacs packages can be distributed
> via ELPA, the above is difficult to achieve. Org promises to support
> older Emacs versions and we cannot rely on all the users using master
> version of Emacs (we cannot even rely on latest Emacs release).

CONTRIBUTE cannot possibly answer all the questions that could arise,
and cannot hold ready recipes for every possible real-life case.  We
can only tell so much there.  Eventually, you need to talk to the
maintainers about the details, and the maintainers already know about
this factoid.

> >> 6. ELPA section is very confusing with this mindset (and in general as
> >>    well).
> >
> > I find nothing confusing there.  All it says is that the Emacs
> > repository doesn't include ELPA, which is a separate repository with
> > its own README file.
> >
> > IOW, all it wants is to prevent people from mistakenly thinking
> > CONTRIBUTE and emacs.git in general cover ELPA.
> 
> The confusion is for the users who do not know what is GNU ELPA.

They should follow the link, and then they will know.  This text is
for those who _do_ know about ELPA, but might make a mistake of
thinking ELPA and Emacs use the same repository and completely share
the development rules and conventions.

Re: On Contributing To Emacs

[Tim Cross]

Stefan Kangas <stefankangas@gmail.com> writes:

> xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> writes:
>
>> - Development velocity is glacial. With releases around once per year
>> and there being no easily accessible distribution mechanism for
>> development updates,
>
> Our core packages can be released straight from master to GNU ELPA
> within 24 hours.  All you need to do, once it is set up (which in itself
> is trivial), is to bump the version header.  This is already the case
> with for example flymake.el and python.el.
>
> So while I agree that it would be good if Emacs could release major
> versions more often (we currently release every two years, AFAICT),
> I don't think this stops packages developed directly on master from
> following a much more frequent release schedule.

I'm not sure more frequent releases of core Emacs is really that
beneficial. A piece of software like Emacs is very mature and the core
does not change that quickly. Less mature and more rapidly evolving
software needs shorter release cycles, but as a system matures, the
cycles generally become longer. Releasing once every 12 months would be
OK if we have the resources to achieve that, but I think for the core
Emacs release, every 24 months is quite reasonable (though, I also
remember a time when new Emacs versions took multiple years, so current
release cycles seem pretty speedy compared to pre-20).

Re: On Contributing To Emacs

[Eli Zaretskii]

> From: Tim Cross <theophilusx@gmail.com>
> Date: Thu, 30 Dec 2021 10:52:12 +1100
> 
> Releasing once every 12 months would be OK if we have the resources
> to achieve that, but I think for the core Emacs release, every 24
> months is quite reasonable (though, I also remember a time when new
> Emacs versions took multiple years, so current release cycles seem
> pretty speedy compared to pre-20).

Yes, we've sped up the release cycle to some extent by enforcing the
rule that minor releases have no new features much more stringently
than it was before Emacs 26, and by using release branches in more
orderly fashion.

As for the relatively long release cycle in general, I said in the
past that many people don't realize the difficulty of releasing a
large, versatile, and stable package such as Emacs.  It is not enough
to make sure that just the new features are working, we also need to
make sure that everything that worked before is still working, and
that is a huge job that takes time, due to disparate use patterns.  It
doesn't help that Emacs is an interactive program, which means a test
suite can only go that far in helping with discovering regressions.
So the experience people have in releasing much smaller and/or less
versatile and/or less interactive packages doesn't scale well when
applied to Emacs.

Re: On Contributing To Emacs

[xenodasein--- via Emacs development discussions.]

Dec 30, 2021, 09:16 by eliz@gnu.org:

> ...
> So the experience people have in releasing much smaller and/or less
> versatile and/or less interactive packages doesn't scale well when
> applied to Emacs.
>

Would it be possible to make an exception for built-in packages that
act as kind of a gateway, like package.el?  It could be developed inside
the previous major release, and have more frequent minor releases.
In practice once in a few months should be enough, if at all.

Re: On Contributing To Emacs

[Stefan Kangas]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> Would it be possible to make an exception for built-in packages that
> act as kind of a gateway, like package.el?  It could be developed inside
> the previous major release, and have more frequent minor releases.
> In practice once in a few months should be enough, if at all.

AFAIU, that is what core packages are for.

Re: On Contributing To Emacs

[xenodasein--- via Emacs development discussions.]

Dec 30, 2021, 13:34 by stefankangas@gmail.com:

> xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> writes:
>
>> Would it be possible to make an exception for built-in packages that
>> act as kind of a gateway, like package.el?  It could be developed inside
>> the previous major release, and have more frequent minor releases.
>> In practice once in a few months should be enough, if at all.
>>
>
> AFAIU, that is what core packages are for.
>

What is a "core package?"  Never seen that term inside Emacs before.
Is package.el one?  If it was on ELPA, what would install it?

Re: On Contributing To Emacs

[Stefan Kangas]

xenodasein@tutanota.de writes:

> What is a "core package?"  Never seen that term inside Emacs before.
> Is package.el one?  If it was on ELPA, what would install it?

If I'm not mistaken, it is only documented in the elpa.git README:

    ** =:core FILES=
    This property has to come first.
    Indicates that this is a special package which will be built by extracting
    files directly from Emacs's source code.  For this to work, the Emacs
    source code should be available in the =emacs= subdirectory.
    FILES specifies the files that will be contained in the generated tarballs.
    It can be a single file name or a list of file names.

FWIW, I suggested adding something about this to CONTRIBUTE, but the
idea was rejected.

Re: On Contributing To Emacs

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sat, 1 Jan 2022 15:50:02 -0500
> Cc: emacs-devel@gnu.org, eliz@gnu.org
> 
> xenodasein@tutanota.de writes:
> 
> > What is a "core package?"  Never seen that term inside Emacs before.
> > Is package.el one?  If it was on ELPA, what would install it?
> 
> If I'm not mistaken, it is only documented in the elpa.git README:
> 
>     ** =:core FILES=
>     This property has to come first.
>     Indicates that this is a special package which will be built by extracting
>     files directly from Emacs's source code.  For this to work, the Emacs
>     source code should be available in the =emacs= subdirectory.
>     FILES specifies the files that will be contained in the generated tarballs.
>     It can be a single file name or a list of file names.
> 
> FWIW, I suggested adding something about this to CONTRIBUTE, but the
> idea was rejected.

Not the idea was rejected, the particular text you proposed and the
place where you proposed to put it were rejected.

Note that the above text is in ELPA's README file.  If you want to add
something similar to the Emacs's README file, I won't mind.  And there
could be perhaps other good places for it, perhaps even a separate
file of some kind.  It just doesn't belong to CONTRIBUTE, at least not
in the form it was proposed, because that doesn't fit the purpose and
the spirit of the instructions in CONTRIBUTE.

Re: On Contributing To Emacs

[No Wayman]

> Does straight.el contain a specific list of packages it 
> recommends?
> Or is that always specified by the user?

Hi, Richard. I co-maintain straight.el with Radon (the original 
author).

Packages are declared via recipe plists in the user's init file.
However, if the user does not specify enough information, the 
remaining recipe information is inherited from recipes provided by 
other sources. Out of the box we provide support for MELPA, 
el-get, a GNU ELPA mirror, Emacsmirror, and Org.

Happy to answer any questions, though I can only speak for myself.
I've CC'd Radon in case he wants to chime in.

~ Nick

Re: On Contributing To Emacs

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

Thanks for the clear answer.

It looks like we would rather add some of the features to our existing
file, package.el.

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

Re: On Contributing To Emacs

[Philip Kaludercic]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> Dec 25, 2021, 23:18 by philipk@posteo.net:
>
>> xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
>> writes:
>>
>>> Dec 25, 2021, 22:03 by eliz@gnu.org:
>>>
>>>> I don't think I understand what you are saying, but the changes
>>>> proposed there were installed 6 months later.
>>>
>>> What I meant was that straight.el should have been a part of Emacs,
>>> in some form, as an improvement of package.el infrastructure.
>>>
>>> Instead, the actual change contributed was primarily a way to disable
>>> package.el.
>>
>> Do you mean that package.el should be extended by straight.el-like
>> functionality, or that straight.el (or a substitute) should be added to
>> Emacs?
>
> The effort spent on it should have both improved existing package.el
> and also add straight.el like functionality to it.  Whether it is all
> under feature 'package or multiple features.

I have been thinking implementing something like this, where package.el
could handle a

      ;; VC: https://source.com/package.git

like header that would indicate where the source code for a package was
being managed and could be downloaded and prepared (autoload, load-path
overriding the default package, ...) when requested.

Building on or in parallel to this, a mechanism to simplify the sending
of patches to the author or friends would also be a good thing to have.

-- 
	Philip Kaludercic

Re: On Contributing To Emacs

[Stefan Kangas]

Philip Kaludercic <philipk@posteo.net> writes:

> I have been thinking implementing something like this, where package.el
> could handle a
>
>       ;; VC: https://source.com/package.git
>
> like header that would indicate where the source code for a package was
> being managed and could be downloaded and prepared (autoload, load-path
> overriding the default package, ...) when requested.

It would be very useful if package.el could be extended in this way.

I also think we should have the capability to just point it at a git
repository and install it as a package, just as straight.el does.  That
way, you wouldn't need support from an upstream that needs to add some
headers.

> Building on or in parallel to this, a mechanism to simplify the sending
> of patches to the author or friends would also be a good thing to have.

Yup.

Re: On Contributing To Emacs

[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 have been thinking implementing something like this, where package.el
  > could handle a

  >       ;; VC: https://source.com/package.git

  > like header that would indicate where the source code for a package was
  > being managed and could be downloaded and prepared (autoload, load-path
  > overriding the default package, ...) when requested.

Could you describe this functionality more concretely, so that people
who don't thoroughly know this field can understand what it would do?

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

Re: On Contributing To Emacs

[Philip Kaludercic]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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 have been thinking implementing something like this, where package.el
>   > could handle a
>
>   >       ;; VC: https://source.com/package.git
>
>   > like header that would indicate where the source code for a package was
>   > being managed and could be downloaded and prepared (autoload, load-path
>   > overriding the default package, ...) when requested.
>
> Could you describe this functionality more concretely, so that people
> who don't thoroughly know this field can understand what it would do?

I am imagining a command like `package-fetch'.  You could give it a
package name or a repository URL, and it would clone the contents into
~/.emacs.d/elpa/devel.  Package.el would treat this as a special kind of
package (next to "installed", "dependency" and "built-in"), hopefully
being able to reuse the existing package-loading functionality.

To me this would demonstrate a real advantage for the practical software
freedom of Emacs users, by having access to both the history of a
package and making contributing to Emacs packages more immediate by
reducing the maintenance overhead.

-- 
	Philip Kaludercic

Re: On Contributing To Emacs

[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 imagining a command like `package-fetch'.  You could give it a
  > package name or a repository URL, and it would clone the contents into
  > ~/.emacs.d/elpa/devel.  Package.el would treat this as a special kind of
  > package (next to "installed", "dependency" and "built-in"), hopefully
  > being able to reuse the existing package-loading functionality.

I see the usefulness of this.

The first step of it -- operating on a package name, which would very likely
point to a repo site that we condemn, would put us into a moral contradiction.
However, there's no moral problem in the rest of it.

Would you like to implement `package-fetch' so that it always wants
a URL as argument?


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

Re: On Contributing To Emacs

[Philip Kaludercic]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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 imagining a command like `package-fetch'.  You could give it a
>   > package name or a repository URL, and it would clone the contents into
>   > ~/.emacs.d/elpa/devel.  Package.el would treat this as a special kind of
>   > package (next to "installed", "dependency" and "built-in"), hopefully
>   > being able to reuse the existing package-loading functionality.
>
> I see the usefulness of this.
>
> The first step of it -- operating on a package name, which would very likely
> point to a repo site that we condemn, would put us into a moral contradiction.
> However, there's no moral problem in the rest of it.
>
> Would you like to implement `package-fetch' so that it always wants
> a URL as argument?

Do you mean to say that there is an issue in just cloning a git
repository from say GitHub?

-- 
	Philip Kaludercic

Re: On Contributing To Emacs

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

  > > The first step of it -- operating on a package name, which would very likely
  > > point to a repo site that we condemn, would put us into a moral contradiction.
  > > However, there's no moral problem in the rest of it.
  > >
  > > Would you like to implement `package-fetch' so that it always wants
  > > a URL as argument?

  > Do you mean to say that there is an issue in just cloning a git
  > repository from say GitHub?

I see various manings for "just cloning a git repository from say
GitHub".  I am not sure what issue you're talking about.  But I think
we are miscommunicating -- talking about two different things.

What I'm saying is, package-fetch should not preference specific web
sites not run by us.  It should definitely NOT preference github,
because we urge people not to put their things on github.

So I suggest that its argument should be a URL, and it should get the
package from that URL.  Whatever URL the user gives.  If the user
specifies a github URL, it would get the package from github.

But it should never spontaneously choose or suggest or prefer github.

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

Re: On Contributing To Emacs

[Philip Kaludercic]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>   > > The first step of it -- operating on a package name, which would very likely
>   > > point to a repo site that we condemn, would put us into a moral contradiction.
>   > > However, there's no moral problem in the rest of it.
>   > >
>   > > Would you like to implement `package-fetch' so that it always wants
>   > > a URL as argument?
>
>   > Do you mean to say that there is an issue in just cloning a git
>   > repository from say GitHub?
>
> I see various manings for "just cloning a git repository from say
> GitHub".  I am not sure what issue you're talking about.  But I think
> we are miscommunicating -- talking about two different things.
>
> What I'm saying is, package-fetch should not preference specific web
> sites not run by us.  It should definitely NOT preference github,
> because we urge people not to put their things on github.
>
> So I suggest that its argument should be a URL, and it should get the
> package from that URL.  Whatever URL the user gives.  If the user
> specifies a github URL, it would get the package from github.
>
> But it should never spontaneously choose or suggest or prefer github.

Ok, I see.  No, there would certainly not be a default inclination
towards GitHub.  Instead my idea was that a package might specify where
to find its repository, and if you enter a package name that has a
header like this:

   ;; VC: https://vcs.host/path/to/repo.git

package-fetch would use this.

-- 
	Philip Kaludercic

Re: On Contributing To Emacs

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

  > Ok, I see.  No, there would certainly not be a default inclination
  > towards GitHub.  Instead my idea was that a package might specify where
  > to find its repository, and if you enter a package name that has a
  > header like this:

  >    ;; VC: https://vcs.host/path/to/repo.git

  > package-fetch would use this.

That's fine -- but note that the packages in NonGNU ELPA should list
NonGNU ELPA as the repo.  They shouldn't refer people to GitHub.

In some cases, the NonGNU ELPA version might contain some of our own
patches.

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

Re: On Contributing To Emacs

[Philip Kaludercic]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>   > Ok, I see.  No, there would certainly not be a default inclination
>   > towards GitHub.  Instead my idea was that a package might specify where
>   > to find its repository, and if you enter a package name that has a
>   > header like this:
>
>   >    ;; VC: https://vcs.host/path/to/repo.git
>
>   > package-fetch would use this.
>
> That's fine -- but note that the packages in NonGNU ELPA should list
> NonGNU ELPA as the repo.  They shouldn't refer people to GitHub.
>
> In some cases, the NonGNU ELPA version might contain some of our own
> patches.

That might be tricky, as a header like this would be added by the
package developer, with the point to ease upstream contribution.
I don't see how this issue could be solved fairly.

-- 
	Philip Kaludercic

Re: On Contributing To Emacs

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

  > > That's fine -- but note that the packages in NonGNU ELPA should list
  > > NonGNU ELPA as the repo.  They shouldn't refer people to GitHub.
  > >
  > > In some cases, the NonGNU ELPA version might contain some of our own
  > > patches.

  > That might be tricky, as a header like this would be added by the
  > package developer, with the point to ease upstream contribution.
  > I don't see how this issue could be solved fairly.

I see your point, and I have an idea.

When the package is maintained in NonGNU ELPA by the developer,
if it points to github, package-fetch could display a gnu.org explanation
of what is bad about github, then clone that repo.  Explaining the problem
would cancel out the problem.

When the version in NonGNU ELPA is not updated from an external repo
then it shouldn't point to an external repo, as that would be confusing.

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

Re: On Contributing To Emacs

[Philip Kaludercic]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>   > > That's fine -- but note that the packages in NonGNU ELPA should list
>   > > NonGNU ELPA as the repo.  They shouldn't refer people to GitHub.
>   > >
>   > > In some cases, the NonGNU ELPA version might contain some of our own
>   > > patches.
>
>   > That might be tricky, as a header like this would be added by the
>   > package developer, with the point to ease upstream contribution.
>   > I don't see how this issue could be solved fairly.
>
> I see your point, and I have an idea.
>
> When the package is maintained in NonGNU ELPA by the developer,
> if it points to github, package-fetch could display a gnu.org explanation
> of what is bad about github, then clone that repo.  Explaining the problem
> would cancel out the problem.
>
> When the version in NonGNU ELPA is not updated from an external repo
> then it shouldn't point to an external repo, as that would be confusing.

I just noticed this shouldn't be a problem at all, as long as the "VC"
header is updated, whenever a package is forked and maintained in NonGNU
ELPA.

-- 
	Philip Kaludercic

Re: On Contributing To Emacs

[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 just noticed this shouldn't be a problem at all, as long as the "VC"
  > header is updated, whenever a package is forked and maintained in NonGNU
  > ELPA.

We should put that into a file of notes for people maintaining NonGNU
ELPA -- as part of a list of things to do in that case.

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

On Contributing To Emacs

[xenodasein--- via Emacs development discussions.]

On Contributing To Emacs

Do not believe the Internet rumors and presume Emacs is hard to change
or improve.

Dealing with a rain of e-mails is not simple, and it is far too easy
to forget that project maintainers are also mere mortals, who are
susceptible to same hardships.

And before saying things like "Why won't they just use that one
website owned by Microshaft?"; please ask yourself whether you actually
have sufficient sociopolitical and historical knowledge on human
condition to make judgments.  In other words, make sure you actually
understand people like RMS, before hotfooting to dismiss them.

In reality you will find them very accommodating, even when you haven't
RTFM'd and did the research.  Especially if you present a sound case.

To the extent that the intended change isn't arguably a good one.

Example:
https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00154.html
https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00433.html

It is one thing wanting to work on "your own" thing.  But making changes
to Emacs just to make that thing more marketable?  Why do I assume so?
This author clearly had the time and ability to make amazing
improvements to Emacs built-in package management process, judging from
their own package.  My intention is not to be confrontational, but it is
sad to think about what could have been achieved...

I find this highly discourteous, but this is only my opinion, and
overall good done is likely still significant.

One could easily be misled from Emacs' splendor, but it actually
doesn't have a huge amount of man-hours at its disposal.  Seemingly
small contributions go a very long way.

Re: On Contributing To Emacs

[Eli Zaretskii]

> Date: Sat, 25 Dec 2021 19:49:18 +0100 (CET)
> From: xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> Example:
> https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00154.html
> https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00433.html
> 
> It is one thing wanting to work on "your own" thing.  But making changes
> to Emacs just to make that thing more marketable?  Why do I assume so?
> This author clearly had the time and ability to make amazing
> improvements to Emacs built-in package management process, judging from
> their own package.  My intention is not to be confrontational, but it is
> sad to think about what could have been achieved...
> 
> I find this highly discourteous, but this is only my opinion, and
> overall good done is likely still significant.

I don't think I understand what you are saying, but the changes
proposed there were installed 6 months later.

Re: On Contributing To Emacs

[xenodasein--- via Emacs development discussions.]

Dec 25, 2021, 22:03 by eliz@gnu.org:

> I don't think I understand what you are saying, but the changes
> proposed there were installed 6 months later.
>

What I meant was that straight.el should have been a part of Emacs,
in some form, as an improvement of package.el infrastructure.

Instead, the actual change contributed was primarily a way to disable
package.el.

Feel free to take this post down, if it is found inappropriate.

Re: On Contributing To Emacs

[Eli Zaretskii]

> Date: Sat, 25 Dec 2021 20:08:56 +0100 (CET)
> From: xenodasein@tutanota.de
> Cc: emacs-devel@gnu.org
> 
> Instead, the actual change contributed was primarily a way to disable
> package.el.

??? The change we are talking about was to introduce the early-init
file, which AFAIU makes the lives of package.el users easier.

Re: On Contributing To Emacs

[xenodasein--- via Emacs development discussions.]

Dec 25, 2021, 22:12 by eliz@gnu.org:

>> Date: Sat, 25 Dec 2021 20:08:56 +0100 (CET)
>> From: xenodasein@tutanota.de
>> Cc: emacs-devel@gnu.org
>>
>> Instead, the actual change contributed was primarily a way to disable
>> package.el.
>>
>
> ??? The change we are talking about was to introduce the early-init
> file, which AFAIU makes the lives of package.el users easier.
>

It also makes display related configurations easier.  This is only my observation
as to why author of straight.el contributed this patch.  If I am wrong, they
would need to have a very good reason for not contributing it directly as
an improvement to Emacs.  My argument is that that reason couldn't have
been "hardness of changing Emacs."

Re: On Contributing To Emacs

[Óscar Fuentes]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> If I am wrong, they
> would need to have a very good reason for not contributing it directly as
> an improvement to Emacs.  My argument is that that reason couldn't have
> been "hardness of changing Emacs."

As of today, straight.el project page says it has 54 contributors. The
roadblock with projects with so many contributors usually is collecting
the required copyright assignments. Other major packages suffer from
this, despite the willingness of their authors/maintainers to put them
under the GNU umbrella.

Re: On Contributing To Emacs

[xenodasein--- via Emacs development discussions.]

Dec 25, 2021, 22:28 by ofv@wanadoo.es:

> As of today, straight.el project page says it has 54 contributors. The
> roadblock with projects with so many contributors usually is collecting
> the required copyright assignments. Other major packages suffer from
> this, despite the willingness of their authors/maintainers to put them
> under the GNU umbrella.
>

But my impression is that core and complex parts of that package
were written by one person.  If it is just a naive disagreement over
licensing, one has to ask oneself; how come I enjoy the fruits of
labor of that license so much as to become deeply familiar with
Emacs internals, and to work on such an advanced package?  Of
course everyone is free to do as their wish, I simply stated my
opinion on finding this situation sad.

Re: On Contributing To Emacs

[Óscar Fuentes]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> But my impression is that core and complex parts of that package
> were written by one person.  If it is just a naive disagreement over
> licensing, one has to ask oneself; how come I enjoy the fruits of
> labor of that license so much as to become deeply familiar with
> Emacs internals, and to work on such an advanced package?  Of
> course everyone is free to do as their wish, I simply stated my
> opinion on finding this situation sad.

Instead of opinions, use facts: ask the author of that package.

Re: On Contributing To Emacs

[Philip Kaludercic]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> Dec 25, 2021, 22:03 by eliz@gnu.org:
>
>> I don't think I understand what you are saying, but the changes
>> proposed there were installed 6 months later.
>
> What I meant was that straight.el should have been a part of Emacs,
> in some form, as an improvement of package.el infrastructure.
>
> Instead, the actual change contributed was primarily a way to disable
> package.el.

Do you mean that package.el should be extended by straight.el-like
functionality, or that straight.el (or a substitute) should be added to
Emacs?

-- 
	Philip Kaludercic

Re: On Contributing To Emacs

[xenodasein--- via Emacs development discussions.]

Dec 25, 2021, 23:18 by philipk@posteo.net:

> xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> writes:
>
>> Dec 25, 2021, 22:03 by eliz@gnu.org:
>>
>>> I don't think I understand what you are saying, but the changes
>>> proposed there were installed 6 months later.
>>>
>>
>> What I meant was that straight.el should have been a part of Emacs,
>> in some form, as an improvement of package.el infrastructure.
>>
>> Instead, the actual change contributed was primarily a way to disable
>> package.el.
>>
>
> Do you mean that package.el should be extended by straight.el-like
> functionality, or that straight.el (or a substitute) should be added to
> Emacs?
>
> -- 
>  Philip Kaludercic
>

The effort spent on it should have both improved existing package.el
and also add straight.el like functionality to it.  Whether it is all under
feature 'package or multiple features.

Re: On Contributing To Emacs

[Stefan Kangas]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> The effort spent on it should have both improved existing package.el
> and also add straight.el like functionality to it.  Whether it is all under
> feature 'package or multiple features.

Sure, agreed.  What can we do about that though?  It is always going to
be tempting to write your own library instead of improving what exists.

Re: On Contributing To Emacs

[xenodasein--- via Emacs development discussions.]

Dec 25, 2021, 22:57 by ofv@wanadoo.es:
> Instead of opinions, use facts: ask the author of that package.

Agreed, I should have done that first.  A fact is though something
made them take that decision.

Dec 26, 2021, 00:53 by stefankangas@gmail.com:
>> xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
>> writes:
>> The effort spent on it should have both improved existing package.el
>> and also add straight.el like functionality to it.  Whether it is all under
>> feature 'package or multiple features.

> Sure, agreed. What can we do about that though? It is always going to
> be tempting to write your own library instead of improving what exists.

That is the question to focus on.  Maybe not being the first author is
a deterrent?   Would something like "Author: emacs-devel" help?

Re: On Contributing To Emacs

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

  > Sure, agreed.  What can we do about that though?  It is always going to
  > be tempting to write your own library instead of improving what exists.

We have to circulate a call for people to think about getting their code
installed in Emacs, when they write it.

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

Re: On Contributing To Emacs

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> The effort spent on it should have both improved existing package.el
> and also add straight.el like functionality to it.  Whether it is all
> under feature 'package or multiple features.

IIRC the whole concept of straight.el is based around pulling packages
off individual authors' repositories.

I don't think that's what we want to do in Emacs.  For example, one such
package provides integration with Apple's dis-service Siri and its
proprietary client shipped with macOS.

Apart from installing packages in such a haphazard fashion, I really
don't see what else straight.el does better than package.el.

Thanks.

Re: On Contributing To Emacs

[Ihor Radchenko]

Po Lu <luangruo@yahoo.com> writes:

> Apart from installing packages in such a haphazard fashion, I really
> don't see what else straight.el does better than package.el.

I do see some advantages:
1. Ability to review actual changes (commits) made in a package since
   last update
2. Ability to maintain a personal set of patches/changes to a package
   while still being able to update to the latest version.

Best,
Ihor

Re: On Contributing To Emacs

[xenodasein--- via Emacs development discussions.]

Po Lu <luangruo@yahoo.com> writes:
> IIRC the whole concept of straight.el is based around pulling packages
> off individual authors' repositories.

> I don't think that's what we want to do in Emacs. For example, one such
> package provides integration with Apple's dis-service Siri and its
> proprietary client shipped with macOS.

> Apart from installing packages in such a haphazard fashion, I really
> don't see what else straight.el does better than package.el.


Dec 26, 2021, 09:56 by yantar92@gmail.com:
> I do see some advantages:
> 1. Ability to review actual changes (commits) made in a package since
> last update
> 2. Ability to maintain a personal set of patches/changes to a package
> while still being able to update to the latest version.


Or to automate building and installing multiple local repositories.  Or
many other things that makes straight.el one of the most popular packages
of all time.

Emacs can be used to write proprietary malware.  From that logic, we
should also stop developing Emacs then.

Re: On Contributing To Emacs

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

Whether there is something to regret in the way straight.el was developed
depends on whether we really want something like that in Emacs.

Does straight.el contain a specific list of packages it recommends?
Or is that always specified by the user?


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

Re: On Contributing To Emacs

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> Does straight.el contain a specific list of packages it recommends?
> Or is that always specified by the user?

I think they're always specified by the user.

Re: On Contributing To Emacs

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@gmail.com>
> Date: Sun, 26 Dec 2021 14:56:44 +0800
> Cc: philipk@posteo.net,
>  "xenodasein--- via Emacs development discussions." <emacs-devel@gnu.org>
> 
> Po Lu <luangruo@yahoo.com> writes:
> 
> > Apart from installing packages in such a haphazard fashion, I really
> > don't see what else straight.el does better than package.el.
> 
> I do see some advantages:
> 1. Ability to review actual changes (commits) made in a package since
>    last update
> 2. Ability to maintain a personal set of patches/changes to a package
>    while still being able to update to the latest version.

package.el can be extended to provide these features, and more.
Patches are welcome.  (Not that I think many users would want these
particular features, but there's no harm in having seldom-used ones.)

Re: On Contributing To Emacs

[Rudolf Adamkovič]

Eli Zaretskii <eliz@gnu.org> writes:

> Not that I think many users would want these particular features, …

Come on!  Who would not want to see the first feature mentioned by Ihor,
namely the ability to review changes?  Even Apple's App Store, designed
for non-technical people, shows more information than Emacs does when it
has pending updates.

Rudy
-- 
"Logic is a science of the necessary laws of thought, without which no
employment of the understanding and the reason takes place." -- Immanuel
Kant, 1785

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: On Contributing To Emacs

[Philip Kaludercic]

Rudolf Adamkovič <salutis@me.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Not that I think many users would want these particular features, …
>
> Come on!  Who would not want to see the first feature mentioned by Ihor,
> namely the ability to review changes?  Even Apple's App Store, designed
> for non-technical people, shows more information than Emacs does when it
> has pending updates.

ELPA checks for a "News" section or file, that are displayed on the
websites elpa.{gnu,nongnu}.org.  package.el could do the same, then you
wouldn't have to parse through a perhaps redundant vcs log and the
incentive to maintain a news section/file would increase.

-- 
	Philip Kaludercic

Re: On Contributing To Emacs

[Stefan Kangas]

Philip Kaludercic <philipk@posteo.net> writes:

> ELPA checks for a "News" section or file, that are displayed on the
> websites elpa.{gnu,nongnu}.org.  package.el could do the same, then you
> wouldn't have to parse through a perhaps redundant vcs log and the
> incentive to maintain a news section/file would increase.

This is sorely needed in package.el, yes.

Re: On Contributing To Emacs

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

  > > ELPA checks for a "News" section or file, that are displayed on the
  > > websites elpa.{gnu,nongnu}.org.  package.el could do the same, then you
  > > wouldn't have to parse through a perhaps redundant vcs log and the
  > > incentive to maintain a news section/file would increase.

Could someone please clarify exactly what is proposed?

Would package.el look for a NEWS section for each of the specific
packages the user has specified?  Or would it look for NEWS files
published by a site such as MELPA that covers lots of packages?

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

Re: On Contributing To Emacs

[Philip Kaludercic]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>   > > ELPA checks for a "News" section or file, that are displayed on the
>   > > websites elpa.{gnu,nongnu}.org.  package.el could do the same, then you
>   > > wouldn't have to parse through a perhaps redundant vcs log and the
>   > > incentive to maintain a news section/file would increase.
>
> Could someone please clarify exactly what is proposed?
>
> Would package.el look for a NEWS section for each of the specific
> packages the user has specified?  Or would it look for NEWS files
> published by a site such as MELPA that covers lots of packages?

What I am proposing (and hope to implement soon) could be a command like
`package-news' that attempts to find a news source in the same manner as
elpa-admin.el does (see `elpaa--get-NEWS' in elpa-admin.el).

-- 
	Philip Kaludercic

Re: On Contributing To Emacs

[Philip Kaludercic]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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 can clone https://git.savannah.gnu.org/cgit/emacs/elpa.git, checkout
>   > the elpa-admin branch and in the file elpa-admin.el line 1332 you find:
>
>   >           (elpaa--get-section
>   >            "News" (elpaa--spec-get pkg-spec :news
>   >                                    '("NEWS" "NEWS.rst" "NEWS.md" "NEWS.org"))
>
>   > This first tries to find a "News" section (like "Commentary"), and in
>   > failing to do so checks for the files "NEWS"", NEWS.rst", "NEWS.md" and
>   > "NEWS.org" in that order.
>
> Thanks, but I'm not sure of what that means.
>
> I don't know what the Lisp program does, because it calls functions I
> don't know about.

The concrete functions are not too necessary, this is just a snippet
from a larger function.  Clone the repository if you are interested in
the defaults.

> I am not sure what the English text means, because it depends on context
> that I don't know.  WHERE does it search for a "News" section -- within what?
> Within certain files, perhaps?  If so, which files?

See (elisp) Library Headers, where it says:

           We use additional stylized comments to subdivide the contents of the
        library file.  These should be separated from anything else by blank
        lines.

One such header that ELPA checks is "News", in whatever ELPA considers
the main file of a project to be.  It might look something like this:

        ;;; News:

        ;; In version 4.2.1 we added the function `foo' and the user
        ;; option `foo-bar`.

> Then it searches for certain file names.  Again, within what?
> Does it search within one specific package?

In case the section was not found, it searches for files in the package
root.

-- 
	Philip Kaludercic

Re: On Contributing To Emacs

[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 such header that ELPA checks is "News", in whatever ELPA considers
  > the main file of a project to be.  It might look something like this:

  >         ;;; News:

  >         ;; In version 4.2.1 we added the function `foo' and the user
  >         ;; option `foo-bar`.

  > > Then it searches for certain file names.  Again, within what?
  > > Does it search within one specific package?

  > In case the section was not found, it searches for files in the package
  > root.

Now I understand.  It seems fine.

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

Re: On Contributing To Emacs

[Eli Zaretskii]

> From: Rudolf Adamkovič <salutis@me.com>
> Cc: luangruo@yahoo.com, philipk@posteo.net, emacs-devel@gnu.org
> Date: Sun, 26 Dec 2021 21:40:53 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Not that I think many users would want these particular features, …
> 
> Come on!  Who would not want to see the first feature mentioned by Ihor,
> namely the ability to review changes?

People who have something useful to do during their day, and who
aren't really interested in examining diffs wrt the previous versions.

Re: On Contributing To Emacs

[Thierry Volpiatto]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Rudolf Adamkovič <salutis@me.com>
>> Cc: luangruo@yahoo.com, philipk@posteo.net, emacs-devel@gnu.org
>> Date: Sun, 26 Dec 2021 21:40:53 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Not that I think many users would want these particular features, …
>> 
>> Come on!  Who would not want to see the first feature mentioned by Ihor,
>> namely the ability to review changes?
>
> People who have something useful to do during their day, and who
> aren't really interested in examining diffs wrt the previous versions.

Isn't this already possible if you make your Elpa directory VC controled?


-- 
Thierry

Re: On Contributing To Emacs

[Philip Kaludercic]

Thierry Volpiatto <thievol@posteo.net> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Rudolf Adamkovič <salutis@me.com>
>>> Cc: luangruo@yahoo.com, philipk@posteo.net, emacs-devel@gnu.org
>>> Date: Sun, 26 Dec 2021 21:40:53 +0100
>>> 
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>> 
>>> > Not that I think many users would want these particular features, …
>>> 
>>> Come on!  Who would not want to see the first feature mentioned by
>>> Ihor,
>>> namely the ability to review changes?
>>
>> People who have something useful to do during their day, and who
>> aren't really interested in examining diffs wrt the previous versions.
>
> Isn't this already possible if you make your Elpa directory VC controled?

You'd get the diffs, but you would loose the content of a proper VCS log
explaining why and what changed.

-- 
	Philip Kaludercic

Re: On Contributing To Emacs

[Rudolf Adamkovič]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Not that I think many users would want these particular features, …
>> 
>> Come on!  Who would not want to see the first feature mentioned by
>> Ihor, namely the ability to review changes?
>
> People who have something useful to do during their day, and who
> aren't really interested in examining diffs wrt the previous versions.

I do have "something useful" to do, and yet, I often await new versions
of packages that fix bugs that block me either at work or at school.  I
fail to see the connection between having "something useful" to do
during my day and wanting to see changes before updating packages.  In
general, if someone wants to update software, they might want to know
why. No?

Rudy
-- 
"'Contrariwise,' continued Tweedledee, 'if it was so, it might be; and
if it were so, it would be; but as it isn't, it ain't. That's logic.'"
-- Lewis Carroll, Through the Looking Glass

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: On Contributing To Emacs

[Eli Zaretskii]

> From: Rudolf Adamkovič <salutis@me.com>
> Cc: yantar92@gmail.com, luangruo@yahoo.com, philipk@posteo.net,
>  emacs-devel@gnu.org
> Date: Mon, 27 Dec 2021 22:27:12 +0100
> 
> In general, if someone wants to update software, they might want to
> know why. No?

Not IME, not usually.  It's a rare case that I see someone actually
read the news.

Re: On Contributing To Emacs

[Stefan Monnier]

>> Apart from installing packages in such a haphazard fashion, I really
>> don't see what else straight.el does better than package.el.
> I do see some advantages:
> 1. Ability to review actual changes (commits) made in a package since
>    last update
> 2. Ability to maintain a personal set of patches/changes to a package
>    while still being able to update to the latest version.

3. `C-h o` jumps to the Git-controlled source file.


        Stefan

Re: On Contributing To Emacs

[Stefan Monnier]

>> The effort spent on it should have both improved existing package.el
>> and also add straight.el like functionality to it.  Whether it is all
>> under feature 'package or multiple features.

100% agreed, but as you surely know it can be harder to do.
Integration is hard.

But the existence of `straight.el` shouldn't deter anyone from improving
`package.el`.  There's a proof of concept implementation of
"straight.el-like facilities via package.el" in the `elpa-admin.el` code
of (Non)GNU ELPA.

And indeed, that's how I install all my packages here.  It's quite
rough around the edges, tho.

> IIRC the whole concept of straight.el is based around pulling packages
> off individual authors' repositories.

Not really.  It's based on the idea of running your installed packages
straight from a Git clone that tracks upstream changes.


        Stefan

Re: On Contributing To Emacs

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

  > >> The effort spent on it should have both improved existing package.el
  > >> and also add straight.el like functionality to it.  Whether it is all
  > >> under feature 'package or multiple features.

This discussion is about "straight.el-like functionality".
Would someone please describe that functionality?
That file is not in Emacs, and I have not seen a description
of what functionality people are talking about.

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

Re: On Contributing To Emacs

[xenodasein--- via Emacs development discussions.]

Before analyzing its functionality, must we also take into account
how widely popular it is?  Popular "starter packs" like Doom
are also built upon it.



Dec 26, 2021, 23:55 by rms@gnu.org:

> This discussion is about "straight.el-like functionality".
> Would someone please describe that functionality?
> That file is not in Emacs, and I have not seen a description
> of what functionality people are talking about.
>
> -- 
> Dr Richard Stallman (https://stallman.org)
> Chief GNUisance of the GNU Project (https://gnu.org)
> Founder, Free Software Foundation (https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)
>

Re: On Contributing To Emacs

[Philip Kaludercic]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> Before analyzing its functionality, must we also take into account
> how widely popular it is?  Popular "starter packs" like Doom
> are also built upon it.

In what way is this significant?

-- 
	Philip Kaludercic

Re: On Contributing To Emacs

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

  > Before analyzing its functionality, must we also take into account
  > how widely popular it is? 

The first question is, "What job does the proposed functionality do?"
The second is, "How do you use it?"

Possible advantages (or disadvantages) come after those two questions.

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

Re: On Contributing To Emacs

[Philip Kaludercic]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>   > >> The effort spent on it should have both improved existing package.el
>   > >> and also add straight.el like functionality to it.  Whether it is all
>   > >> under feature 'package or multiple features.
>
> This discussion is about "straight.el-like functionality".
> Would someone please describe that functionality?

straight.el is an alternative package manager that for the purposes of
this thread clones a Git repository directly instead of fetching the
package contents from a package archive like ELPA.  I believe it does a
bit more along the lines of functional package managers like Nix and
Guix, but I haven't used it myself to be able to say what difference it
makes.

-- 
	Philip Kaludercic

Re: On Contributing To Emacs

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

  > straight.el is an alternative package manager that for the purposes of
  > this thread clones a Git repository directly instead of fetching the
  > package contents from a package archive like ELPA.

Thanks.

When you say "package manager", do you mean something like apt which
manages a fixed set of packages, or something like package.el which manages
a custom set of packages that the user specifies?

  >   I believe it does a
  > bit more along the lines of functional package managers like Nix and
  > Guix,

Guix is like apt -- it manages a set of packages provided by a site.
I think the same is true of Nix.


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

Re: On Contributing To Emacs

[Philip Kaludercic]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>   > straight.el is an alternative package manager that for the purposes of
>   > this thread clones a Git repository directly instead of fetching the
>   > package contents from a package archive like ELPA.
>
> Thanks.
>
> When you say "package manager", do you mean something like apt which
> manages a fixed set of packages, or something like package.el which manages
> a custom set of packages that the user specifies?

Neither is really fixed or really custom.  I can configure a list of
repositories that are updated and extended over time.  The difference to
me is that APT (DNF, Pacman, Guix, Nix, ...) are system package managers
while package.el (pip, gem, OPAM, go install, ...) are language/program
specific package managers.

>   >   I believe it does a
>   > bit more along the lines of functional package managers like Nix and
>   > Guix,
>
> Guix is like apt -- it manages a set of packages provided by a site.
> I think the same is true of Nix.

I mention Guix because of the "functional" aspect of package managing
(reproducible builds, atomic transactions, the ability to revert).  It
does not replace a system package manager.

-- 
	Philip Kaludercic

Re: On Contributing To Emacs

[Stefan Monnier]

BTW,

It's probably not very hard to change `straight.el` such that the
packages it installs are found and recognized by `package-activate-all`.


        Stefan

Re: On Contributing To Emacs

[Stefan Kangas]

Richard Stallman <rms@gnu.org> writes:

> This discussion is about "straight.el-like functionality".
> Would someone please describe that functionality?
> That file is not in Emacs, and I have not seen a description
> of what functionality people are talking about.

From straight.el/README.md:

  ## Features

  * Install Emacs packages listed on [MELPA], [GNU ELPA][gnu-elpa], or
    [Emacsmirror], or provide your own recipes.
  * Packages are cloned as Git (or other) repositories, not as opaque
    tarballs.
  * Make changes to a package simply by editing its source code, no
    additional steps required. Contribute upstream just by pushing your
    changes.
  * Powerful interactive workflows (with popups à la Magit) for
    performing bulk maintenance on the Git repositories for your
    packages.
  * Save and load version lockfiles that ensure 100% reproducibility for
    your Emacs configuration. Package state is defined entirely by your
    init-file and (optional) lockfile, with no extra persistent data
    floating around.
  * Specify package descriptions using a powerful format based on [MELPA
    recipes][melpa-recipe-format] (with a familiar but improved syntax).
  * [`use-package`][use-package] integration.
  * Modular: you can install your packages manually and straight.el will
    load them for you. Or you can also have straight.el install your
    packages, while you provide the recipes explicitly. Or straight.el
    can also fetch recipes, if you want. Bulk repository management and
    package updates are also optional.
  * Extensible APIs to add new recipe sources and version-control
    backends.
  * The cleanest source code you've ever seen. [45%][#trivia/comments]
    of `straight.el` is comments and docstrings.

  Note: `straight.el` is a replacement for `package.el`, **not**
  `use-package`. `use-package` can be used with either `package.el` or
  `straight.el`.

Also note that this file says:

  straight.el has a philosophy which is fundamentally incompatible with
  package.el, and non-compatibility with package.el is one of its design
  goals.

Re: On Contributing To Emacs

[Stefan Monnier]

> Also note that this file says:
>
>   straight.el has a philosophy which is fundamentally incompatible with
>   package.el,

This is a probably misunderstanding on the part of `straight.el`s author
(or an over-generalization).  It's not compatible with the ELPA
infrastructure that lets one download and install tarballs from HTTP
servers, but its philosophy is definitely compatible with the part of
`package.el` which deals with finding the installed packages, choosing
which ones to activate, and in which order (taking dependencies into
account).


        Stefan

Re: On Contributing To Emacs

[xenodasein--- via Emacs development discussions.]

Dec 27, 2021, 01:11 by monnier@iro.umontreal.ca:

>> Also note that this file says:
>>
>>  straight.el has a philosophy which is fundamentally incompatible with
>>  package.el,
>>
>
> This is a probably misunderstanding on the part of `straight.el`s author
> (or an over-generalization).  It's not compatible with the ELPA
> infrastructure that lets one download and install tarballs from HTTP
> servers, but its philosophy is definitely compatible with the part of
> `package.el` which deals with finding the installed packages, choosing
> which ones to activate, and in which order (taking dependencies into
> account).
>
>
>  Stefan
>

+1

Re: On Contributing To Emacs

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

  > >From straight.el/README.md:

Thanks for sending me this.

    > ## Features

    > * Install Emacs packages listed on [MELPA], [GNU ELPA][gnu-elpa], or
    >   [Emacsmirror], or provide your own recipes.

We do not want it to refer to MELPA or Emacsmirror.
That would put us in the position of legitimizing nonfree packages,
and treating that distinction as a side issue.

Fixing this would not be a big change, or difficult, but that
doesn't make it less important.

    > * Specify package descriptions using a powerful format based on [MELPA
    >   recipes][melpa-recipe-format] (with a familiar but improved syntax).

We would need to study the consequences of this feature, before
deciding whether we ought to support something like this.  What sorts
of situations do people use it for?  Why aren't packages directly usable
in the form that they are published?

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

Re: On Contributing To Emacs

[Philip Kaludercic]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>   > >From straight.el/README.md:
>
> Thanks for sending me this.
>
>     > ## Features
>
>     > * Install Emacs packages listed on [MELPA], [GNU ELPA][gnu-elpa], or
>     >   [Emacsmirror], or provide your own recipes.
>
> We do not want it to refer to MELPA or Emacsmirror.
> That would put us in the position of legitimizing nonfree packages,
> and treating that distinction as a side issue.
>
> Fixing this would not be a big change, or difficult, but that
> doesn't make it less important.

I believe straight.el (the maintainer and contributors) is part of the
MELPA-adjacent "milieu", so I don't think anyone could really make them
change their mind.

This shouldn't matter either way if the important functionality is
replicated in package.el.  I have always had the impression that the
primary author (Radon Rosborough) has a tendency for over-engineering
his packages, many of which would have been welcome additions to ELPA or
Emacs, but have since been simplified or re-implemented ("CTRLF", a
isearch-in the minibuffer has "isearch-mb", "Selectrum", a narrowing
completion framework has "Vertico", "el-patch", a system to patch)

>     > * Specify package descriptions using a powerful format based on [MELPA
>     >   recipes][melpa-recipe-format] (with a familiar but improved syntax).
>
> We would need to study the consequences of this feature, before
> deciding whether we ought to support something like this.  What sorts
> of situations do people use it for?  Why aren't packages directly usable
> in the form that they are published?

* Not all packages are immediately added to an ELPA.  It is often the
  case that a developer might develop it for a while in a Git
  repository, before submitting it somewhere.  This feature allows a
  curious user to install it, as if it were a package

* The same can happen for features, a developer might maintain on a
  separate branch.  If a user is interested in testing and giving
  feedback, they might want to use this branch before it is released.

* If for whatever reason a package maintainer falls behind, and a fork
  continues development, you could simply specify the repository of the
  fork and use that instead.

-- 
	Philip Kaludercic

Re: On Contributing To Emacs

[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 believe straight.el (the maintainer and contributors) is part of the
  > MELPA-adjacent "milieu", so I don't think anyone could really make them
  > change their mind.

  > This shouldn't matter either way if the important functionality is
  > replicated in package.el.

That's a valid point.

  > * Not all packages are immediately added to an ELPA.  It is often the
  >   case that a developer might develop it for a while in a Git
  >   repository, before submitting it somewhere.  This feature allows a
  >   curious user to install it, as if it were a package

I don't follow the logic -- perhaps because you've stated your idea in
an abstract way.  You have something in mind but your words don't
explain it to people like me.

Why is anything special needed to "install the package as if it were a
package"?  What does that even mean?  Why isn't it enough just to
instantiate its repository and use it straightaway?

  > * If for whatever reason a package maintainer falls behind, and a fork
  >   continues development, you could simply specify the repository of the
  >   fork and use that instead.

Isn't this part of normal use of git?

What job is the "formula" supposed to do?

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

Re: On Contributing To Emacs

[LdBeth]

>>>>> In <E1n23zC-0007fx-Vq@fencepost.gnu.org> 
>>>>>	Richard Stallman <rms@gnu.org> wrote:
RMS> Why is anything special needed to "install the package as if it were a
RMS> package"?  What does that even mean?  Why isn't it enough just to
RMS> instantiate its repository and use it straightaway?

Basically, users of straight.el feel that it would be cool to have all
the jobs of clone and update git repos, compile elisp files and setup
the load-path been done "automatically", with only one line in their
.emacs.el, and all expecting that should be "dumb proof" enough that
copying their .emacs.el to another machine (possibly running different
OS) with out the elpa/ directories and the repos of external emacs
plugins can still bootstrap and reproduce the same Emacs environment,
with minimized manual intervention.

The above scenario is common among people who are sharing their
.emacs.el files to those have no time/no experience to building their
own emacs configurations.

Hope that could resolve the uncertainty.

-- 
LDB