On Tue, Jan 7, 2025 at 1:48 PM Patrick Steinhardt <ps@xxxxxx> wrote: > > On Mon, Jan 06, 2025 at 02:25:23PM +0100, Christian Couder wrote: > > On Mon, Jan 6, 2025 at 8:51 AM Patrick Steinhardt <ps@xxxxxx> wrote: > > > > > > The "linux-gcc-default" job is mostly doing the same as the "linux-gcc" > > > job, except for a couple of minor differences: > > > > > > - We use an explicit GCC version instead of the default version > > > provided by the distribution. We have other jobs that test with > > > "gcc-8", making this distinction pointless. > > > > > > - We don't set up the Python version explicitly, and instead use the > > > default Python version. Python 2 has been end-of-life for quite a > > > while now though, making this distinction less interesting. > > > > > > - We set up the default branch name to be "main" in "linux-gcc". We > > > have other testcases that don't and also some that explicitly use > > > "master". > > > > > > So overall, the job does not add much to our test coverage. Merge it > > > into our "linux-gcc" job to reduce our test matrix a bit. > > > > I understand that the subject uses "merge" as the space is limited > > there, but it might be better to be a bit more explicit here about > > what the patch is doing, which is: > > > > - making the "linux-gcc" job use the default version of gcc provided > > by the distribution (which is ubuntu-20.04) instead of "gcc-8", > > - removing the "linux-gcc-default" job. > > But isn't that what "merging" is about? One merges the diff of side A > into B and then removes A. I don't have an idea for a better subject, > honestly. My comment was saying that it was fine to use "merge" in the subject, but that, in the body part of the commit message, it would be better if there were more details about what the commit is actually doing. When the commit message is not clear about what the commit does, it's difficult to check that the changes in the commit were intended.
