On 03.04.2024 15:11, Christophe Lyon wrote: > On Wed, 3 Apr 2024 at 10:30, Jan Beulich <jbeul...@suse.com> wrote: >> >> On 03.04.2024 10:22, Christophe Lyon wrote: >>> Dear release managers and developers, >>> >>> TL;DR: For the sake of improving precommit CI coverage and simplifying >>> workflows, I’d like to request a patch submission policy change, so >>> that we now include regenerated files. This was discussed during the >>> last GNU toolchain office hours meeting [1] (2024-03-28). >>> >>> Benefits or this change include: >>> - Increased compatibility with precommit CI >>> - No need to manually edit patches before submitting, thus the “git >>> send-email” workflow is simplified >>> - Patch reviewers can be confident that the committed patch will be >>> exactly what they approved >>> - Precommit CI can test exactly what has been submitted >>> >>> Any concerns/objections? >> >> Yes: Patch size. And no, not sending patches inline is bad practice. > Not sure what you mean? Do you mean sending patches as attachments is > bad practice?
Yes. It makes it difficult to reply to them (with proper reply context). >> Even assuming sending patches bi-modal (inline and as attachment) works >> (please indicate whether that's the case), it would mean extra work on >> the sending side. >> > For the CI perspective, we use what patchwork is able to detect as patches. > Looking at recent patches submissions, it seems patchwork is able to > cope with the output of git format-patch/git send-email, as well as > attachments. > There are cases where patchwork is not able to detect the patch, but I > don't know patchwork's exact specifications. Question was though: If a patch was sent inline plus attachment, what would CI use as the patch to apply? IOW would it be an option to attach the un-stripped patch, while inlining the stripped one? Jan
