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

Previous Next

Full log

View this message in rfc822 format

From: david <davidimagid <at> gmail.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Philip Kaludercic <philipk <at> posteo.net>, 76925 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, monnier <at> iro.umontreal.ca
Subject: bug#76925: [PATCH] admin/notes/elpa: Add note on contributing to external packages
Date: Sat, 22 Mar 2025 21:20:38 -0400

[Message part 1 (text/plain, inline)]

Stefan Kangas <stefankangas <at> gmail.com> writes:

> BTW, which Emacs mode are you editing this in to automatically insert
> 0x2019?
>
I manually used the ’ character in the text.

>> +1. Include clear contribution guidelines in your repository
>> +   If you include a README or CONTRIBUTING file in your external
>> +   repository, consider adding the following:
>> +   - A notice that the package is distributed through GNU ELPA.
>> +   - A statement that contributors must assign copyright for their
>> +     contributions to the FSF if the contribution is significant
>> +     (e.g., more than a few lines of code, following the fifteen-line
>> +     thumb-rule).
>
> Clarify what is the "fifteen-line thumb-rule" here.
>
>> +   - For complete information, see the CONTRIBUTE file in the Emacs
>> +     repository.
>> +
>> +2. Handling contributions requiring copyright assignment
>> +   When a contributor submits a pull request or patch that requires
>> +   copyright assignment:
>> +   - Acknowledge the contribution: Thank the contributor and let them
>> +     know that their contribution will need to go through the FSF’s
>> +     copyright assignment process before it can be merged.
>> +   - Explain the process: Provide the contributor with clear
>> +     instructions on how to complete the copyright assignment process.
>> +     This typically involves:
>> +     - Filling out the FSF’s copyright assignment form.
>> +     - Sending the signed form to the FSF.
>> +     - Waiting for confirmation from the FSF that the assignment has
>> +       been processed.
>
> Instead of "typically", say "always".
>
>> +   - Point to resources: Direct the contributor to the FSF’s copyright
>> +     assignment page for more information:
>> +     https://www.fsf.org/licensing/assigning.html
>
> The bullet point headings "Acknowledge the contribution", "Explain the
> process", "Point to resources" can be taken out.
>
>> +3. Consult with GNU ELPA administrators
>> +   If you’re unsure whether a contribution requires copyright
>> +   assignment or how to handle a specific case:
>> +   - Reach out to the GNU ELPA administrators by emailing
>> +     emacs-devel <at> gnu.org.
>> +   - Provide details about the contribution (e.g., the size of the
>> +     patch, the contributor’s contact information, and any relevant
>> +     context).
>
> Change "contact information" to "email address".  We don't need or want
> more specific information than that.
>
>> +4. Merging contributions
>> +   Once the contributor has completed the copyright assignment process
>> +   and you’ve received confirmation from the FSF:
>> +   - Merge the contribution into your external repository.  Note that
>> +     repositories under `elpa.git` should not be modified directly by
>> +     Emacs developers, as their upstreams are not expected to merge
>> +     changes made there.  Instead, contributions should be made to the
>> +     external repository and then synchronized with `elpa.git`.
>
> Yes.
>
>> +     However, if the upstream development appears to have stagnated and
>> +     the maintainers are unreachable, the GNU ELPA administrators may
>> +     commit changes directly to `elpa.git` to ensure the package remains
>> +     functional and up-to-date.
>
> This is not our process in that case.  We would reach out to upstream,
> look for a new maintainer, etc.  IOW, many other steps become relevant
> before we take that drastic step.
>
> In particular, we would always set `:url nil` first.
>
>> +   - In exceptional cases, minor local changes may be made directly in
>> +     `elpa.git` (e.g., to adapt the package to the ELPA environment).
>> +     However, these changes will not be reflected in the upstream
>> +     repository and should be kept to a minimum.
>
> I wouldn't mention this here.  "Be kept to a minimum" is a bit
> misleading, since AFAIK this has never happened.  If we should say
> anything, we should say that.
>
>> +   - Make sure to credit the contributor in the commit history.
>> +   - If applicable, update the AUTHORS or THANKS file in your
>> +     repository to acknowledge their contribution.
>
> Fair enough, but do we really need to repeat that?
>
>> +5. Maintaining compliance
>> +   - It’s a good idea to periodically review your repository’s
>> +     contribution guidelines to keep them up-to-date and aligned with
>> +     GNU ELPA policies.
>
> What would this look like?  I'm not aware that any maintainer is doing
> specific review work besides what happens when new contributors show up.
>
>> +   - Stay in touch with the GNU ELPA administrators to address any
>> +     questions or concerns about contributions and copyright assignment.
>
> I'm even less sure what this might concretely look like.
>
>> +By following these steps, you can help ensure that contributions to your
>> +externally hosted package are handled in a way that complies with GNU
>> +ELPA policies and respects the FSF’s copyright requirements.
>
> I'm not sure what this paragraph specifically adds.
>
> In general, I'm not sure about the intended target audience for this
> documentation.  The documentation in admin/notes is usually directed at
> people maintaining Emacs, while documentation directed at package
> maintainers usually go to elpa.git/README (and related files).
>
The addition of this section aims to provide guidance for new GNU ELPA
package developers.  It serves as a reminder in admin/notes about the
process for accepting contributions and maintaining packages, ensuring
ongoing compliance with GNU ELPA licensing policies.

> Maybe we should keep only the small note that boils down to:
>
>     Don't commit changes directly to packages in GNU ELPA without
>     checking first that they have :url nil.
>
> And related explanations.

I've attached the updated patch incorporating your feedback, emphasizing
the need to check `:url nil` before direct commits to GNU ELPA.  I'll
wait for further instructions to proceed.

[0001-Add-note-about-externally-hosted-packages-to-admin-n.patch (text/x-patch, attachment)]

Previous Next

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