This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Contribution checklist v2
- From: Siddhesh Poyarekar <siddhesh at gotplt dot org>
- To: GLIBC Devel <libc-alpha at sourceware dot org>, Carlos O'Donell <carlos at redhat dot com>
- Date: Mon, 7 Oct 2019 13:02:37 -0400
- Subject: Contribution checklist v2
Carlos,
What do you think of the following TL;DR; section at the top of the
checklist:
~~~~~
In summary, here is a high level list of things to do to get your
patches into glibc:
* Make sure you have signed papers to assign copyright to the FSF
* Clone the
[[https://sourceware.org/git/?p=glibc.git;a=summary|repository]]
* Hack on code in your repository
* If you're fixing a bug, file a
[[https://sourceware.org/glibc/wiki/Bugzilla%20Procedures|bug report]]
* Test your changes
* Commit the changes into your repository, making sure to rebase on top
of latest master
* Create one or more patches using `git format-patch`
* Use `git send-email --to=libc-alpha@sourceware.org` to send the patch
to the list, using --cc to get the attention of specific
[[https://sourceware.org/glibc/wiki/Bugzilla%20Procedures|maintainers]]
if needed.
* Ping at least weekly if your patch has not been reviewed yet
* On approval, commit the patch if you have access, or ask the reviewer
to commit for you
~~~~~
In fact, I wonder if it makes sense to drop the Testing section
altogether and link to the Testing wiki page. What else can we drop to
make that page (and the process) less complicated?
Siddhesh
PS: I've dropped the ChangeLog section in that page and replaced it with
a note pointing to the changelog generation script.