This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Contribution checklist v2

On 10/7/19 1:02 PM, Siddhesh Poyarekar wrote:
> 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
> [[;a=summary|repository]]
>  * Hack on code in your repository
>  * If you're fixing a bug, file a
> [[|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 send the patch
> to the list, using --cc to get the attention of specific
> [[|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
> ~~~~~

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 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.

Looks great!


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]