GNU bug report logs - #76925
[PATCH] admin/notes/elpa: Add note on contributing to external packages

Previous Next

Full log

Message #53 received at 76925 <at> debbugs.gnu.org (full text, mbox):

From: david <davidimagid <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, philipk <at> posteo.net, 76925 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca, stefankangas <at> gmail.com
Subject: Re: bug#76925: [PATCH] admin/notes/elpa: Add note on contributing
 to external packages
Date: Sun, 23 Mar 2025 09:27:38 -0400

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

>> From: david <davidimagid <at> gmail.com>
>> Cc: 76925 <at> debbugs.gnu.org,  Po Lu <luangruo <at> yahoo.com>,  Philip Kaludercic
>>  <philipk <at> posteo.net>,  Eli Zaretskii <eliz <at> gnu.org>,  Stefan Kangas
>>  <stefankangas <at> gmail.com>
>> Date: Sun, 23 Mar 2025 07:45:45 -0400
>> 
>> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> 
>> > I don't understand this.  Who is this for?  What problem does it aim to solve?
>> > Why hide it in that location?
>> >
>> >
>> >         Stefan "who hasn't looked at the presumably preceding discussion
>> >                 in emacs-devel"
>> 
>> This discussion started on emacs-devel but was moved here to
>> bug-gnu-emacs for further review and tracking.  If you think this
>> information should also go elsewhere, I'm happy to do that.  However, I
>> don't believe admin/notes/elpa is a hidden location for Emacs
>> developers.
>
> Why do you think admin/notes/elpa is not a hidden location for Emacs
> developers?  Who do you think the admin/notes/ directory is for?
>
Eli, are you suggesting this section should be added to a more visible
location than admin/notes/elpa?  If so, I'm happy to propose adding it
elsewhere.  I chose admin/notes/elpa because it was one of the places I
looked for this information and noticed it was missing.  I also checked
the elpa README and found it lacking there as well.  Of course, it's up
to the Emacs maintainers to decide the best location for this section.

>> Related questions that may arise:
>
> Who may raise this questions, and in what contexts?
>
The proposed section helps Emacs and GNU ELPA developers ensure their
code is up-to-date and compliant with Emacs policies.  It addresses
questions arising during contributions, updates, or policy reviews.

>> - Are these cases considered policy violations for packages in GNU ELPA?
>
> Which cases, and why do you think they might be policy violations?
>
The cases I'm referring to are when a built-in package or a GNU ELPA
package continues development outside GNU ELPA without adhering to its
policies.

>> The proposed section in the Emacs developer notes aims to address these
>> questions in a general sense
>
> How can a question be addressed "in a general sense"?  Shouldn't every
> question be addressed specifically and in a targeted manner, answering
> exactly the question and nothing else?
>
The focus is on helping developers navigate GNU ELPA package maintenance
in external repositories.  Specific details can be added if needed.

>> When GNU ELPA policies are violated—or could be violated,
>> such as by accepting a pull request or incorporating code that is not
>> under FSF copyright—Emacs maintainers and developers will have the
>> clarity and guidelines needed to take appropriate action and defend GNU
>> Emacs' interests.
>
> If code that violates the policies is accepted, how can the Emacs
> maintainers do anything post-factum to defend GNU interests?  Code
> that is accepted into the Git repository is carved in stone, and
> cannot be removed from Git, ever.

That's precisely the point.  Maintainers of GNU ELPA packages hosted
externally need clear guidelines for proper maintenance.  The GNU ELPA
team must review updates before merging them to ensure compliance with
Emacs policies.  This includes verifying that contributors with
significant changes (e.g., over 15 lines of code) complete the FSF
copyright assignment process, notifying maintainers of policy
violations, etc.  While I'm unfamiliar with the current process, I
propose adding a section to guide external maintainers on GNU ELPA best
practices.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.