This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Contribution checklist v2
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Florian Weimer <fw at deneb dot enyo dot de>
- Cc: Carlos O'Donell <carlos at redhat dot com>, Siddhesh Poyarekar <siddhesh at gotplt dot org>, GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Mon, 7 Oct 2019 21:28:03 +0000
- Subject: Re: Contribution checklist v2
- Ironport-sdr: +0MnFVLPDYogD8U9LB7AtqpycOR2sh+RcQ0mNNgTu8ykLl1sZ+BztXHU3YB7PCowlUurhj7s6n 2HY9ajEstEOrGhLf45GuDx6nZrphnE2EW19KXw0Fdh6fRz3IXBcHIAgegXjRfZaRXe1rS2veiJ 8ETs7jj/wxq83eFj60jhmiXqeICnhGD9QiP71uAmK/XcxwgzxHbKH0d/pBBCPhrVUdIYo23kYZ iQOjT6mMCohnQIfrZ8fIuhJ0N5YYXcmw5RDGmT3wNWGL6pWmz7NHeSEGxowlBebYYZLKBdrfJr QJE=
- Ironport-sdr: 7VVzwLQex0VXtriHsKNxJw9e2LJNIhRRfVBA1TPId2yZ1Qw3fGc6z1WpiDeODkDOFhdF6B3x/r oz5jkavV8EuuUCM6yF+K8d90F0aDhgHQRafFcEtsStXG9y4GI4iBeE6hio4oQ2o3th1oC9s33w ipSfGByGgOlRLqjhPg4q2ZNEJsNJ31haLrCoxHjUqoHJ1joVyTlnPuHoPzfj4AZIGkVp0MJ8yE SNQWDs0NqOoPSyxBT8yiLNv3Vqk4UyLhB8NIK5b3HYEe59l9zoHEueWdcCwaxjFhCImjKk+gCR p3Q=
- References: <b71c9a57-7e3c-fc22-0c72-7b936eb3aafc@gotplt.org> <3ee782c6-931e-194a-b649-7ec426407940@redhat.com> <alpine.DEB.2.21.1910072045360.19789@digraph.polyomino.org.uk> <877e5gckyn.fsf@mid.deneb.enyo.de>
On Mon, 7 Oct 2019, Florian Weimer wrote:
> * Joseph Myers:
>
> > On Mon, 7 Oct 2019, Carlos O'Donell wrote:
> >
> >> There is a difference between testing for commit vs. testing in general.
> >
> > A key thing about testing for commit is *describe the testing you did in
> > the commit message*. That way, a reviewer has the information needed to
> > consider whether the testing described was sufficient for the patch in
> > question or not.
>
> When you say “in the commit message”, do you mean that this
> information should be committed to Git, too?
In my view it should be included in the commit message, as committed to
git. That way, if an issue shows up later with the change, the
information is immediately there in git to see what was covered in the
initial testing and what wasn't.
In most cases this information is short and simple - naming an
architecture on which the testsuite was run, or saying the change was
tested with build-many-glibcs.py.
--
Joseph S. Myers
joseph@codesourcery.com