This is the mail archive of the
mailing list for the glibc project.
Re: Contribution checklist v2
- From: Carlos O'Donell <carlos at redhat dot com>
- To: Siddhesh Poyarekar <siddhesh at gotplt dot org>, GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Mon, 7 Oct 2019 13:56:56 -0400
- Subject: Re: Contribution checklist v2
- References: <firstname.lastname@example.org>
On 10/7/19 1:02 PM, Siddhesh Poyarekar wrote:
> What do you think of the following TL;DR; section at the top of the
> 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
> * 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 --email@example.com` to send the patch
> to the list, using --cc to get the attention of specific
> 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
That summary looks good to me.
> 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?
There is a difference between testing for commit vs. testing in general.
I would be OK linking with the testing wiki page if it had a section on
"minimal testing before commit" where we need to talk briefly about testing
on as many arches as you can, and running build-many-glibcs.py if you are
touching headers across arches or kernels.
> PS: I've dropped the ChangeLog section in that page and replaced it with
> a note pointing to the changelog generation script.