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

Previous Next

Full log

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

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

david <davidimagid <at> gmail.com> writes:

> Updated patch incorporating feedback:
>
> - Adjusted tone to be more collaborative.
> - Clarified GNU ELPA admins' role in upstream stagnation.
> - Ensured consistent sentence case in headings.
>
> Please review and suggest further improvements.
>
> Thanks,
> David D.
>
> From 09842ebfbf8b123351bdec9c05e4aedff7ab640d Mon Sep 17 00:00:00 2001
> From: dimagid <dimagidve <at> gmail.com>
> Date: Mon, 10 Mar 2025 08:39:40 -0400
> Subject: [PATCH Bug#76925] Add note about externally hosted packages to
>  admin/notes/elpa
>
> This commit adds a section to admin/notes/elpa documenting best practices
> for maintaining externally hosted GNU ELPA packages.  It covers contribution
> guidelines, copyright assignment, and synchronization with elpa.git, while
> emphasizing a collaborative and relaxed approach to package maintenance.
> ---
>  admin/notes/elpa | 77 ++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 77 insertions(+)
>
> diff --git a/admin/notes/elpa b/admin/notes/elpa
> index afcda71d1dd..6a5f2a5c360 100644
> --- a/admin/notes/elpa
> +++ b/admin/notes/elpa
> @@ -33,3 +33,80 @@ the package.
>  
>  It is easy to use the elpa branch to deploy a "local" copy of the
>  package archive.  For details, see the README file in the elpa branch.
> +
> +* Contributing to externally hosted packages
> +
> +Some GNU ELPA packages are primarily developed in external repositories
> +(e.g., on GitHub, GitLab, or similar platforms).  If you maintain such
> +a package, it’s important to help contributors understand the
> +requirements for contributing, especially when it comes to copyright
> +assignment to the Free Software Foundation (FSF).  Here’s what you can
> +do:
> +
> +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).
> +   - 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.
> +   - Point to resources: Direct the contributor to the FSF’s copyright
> +     assignment page for more information:
> +     https://www.fsf.org/licensing/assigning.html
> +
> +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).
> +
> +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`.
> +     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.
> +   - 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.
> +   - 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.
> +
> +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.
> +   - Stay in touch with the GNU ELPA administrators to address any
> +     questions or concerns about contributions and copyright assignment.
> +
> +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.

Hello everyone,

I wanted to check if there’s any feedback on this PATCH. It was updated
on the 12th of this month, incorporating previous recommendations and
suggestions, but I haven’t received any further comments since
then. Could you let me know what steps are needed to move forward with
incorporating this change?

Thank you in advance!

Previous Next

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