From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 3AA921F4BD for ; Wed, 2 Oct 2019 09:30:43 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:subject:references:date:in-reply-to :message-id:mime-version:content-type:content-transfer-encoding; q=dns; s=default; b=jUaocS7TU/YYZawZvL8D25RAhc13t4RTqM5GbtIdy6m i4hr5CNbai7zmKryH/OtemUf7IANCeIaumYDuIfTDSyZFUAR+aKEee2wiJ7vFA2G p4oXsoSRZ4HxZ3P6uoKolN/1HnLNTvegysrktaZXm8YC2SrmL1WKUC51qqRK+jSE = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:subject:references:date:in-reply-to :message-id:mime-version:content-type:content-transfer-encoding; s=default; bh=NPmu80bG+5BiyaMbnYNGSnEccuc=; b=adCCjr6CE2Tb0ncXJ EbrLOw8LMuhiMD9wLjTlLss2okxWpUgP2V8dPNn053/vXalp3TcPRazHZLzOwHNI 15DSKFEY4rxZ7JiaIBjWKtSH75i9APaRvcld9u0Q/iCOgFYfxXiyNqC1oy4l6CyJ mdtYCsmfdaYssTGS8Sr7ye1uXE= Received: (qmail 60288 invoked by alias); 2 Oct 2019 09:30:38 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 57386 invoked by uid 89); 2 Oct 2019 09:30:24 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mx1.redhat.com From: Florian Weimer To: Subject: Re: When can we stop writing ChangeLogs? References: <6ebd0e52-a18f-15fc-f4ab-cf2c3afc74e9@gotplt.org> <3bd4b069-e16b-af68-fb2f-17d2458bece5@redhat.com> <878sq522xz.fsf@oldenburg2.str.redhat.com> <52634368-ee1e-23d1-1d61-de0057e03829@gotplt.org> <87ftkdzl4v.fsf@oldenburg2.str.redhat.com> <87v9t8s6qm.fsf@oldenburg2.str.redhat.com> Date: Wed, 02 Oct 2019 11:30:15 +0200 In-Reply-To: <87v9t8s6qm.fsf@oldenburg2.str.redhat.com> (Florian Weimer's message of "Tue, 01 Oct 2019 19:41:53 +0200") Message-ID: <87d0ffsdeg.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable * Florian Weimer: > * Joseph Myers: > >> On Mon, 30 Sep 2019, Florian Weimer wrote: >> >>> I'm looking for something far simpler here=E2=80=94a script that submit= ters and >>> reviewers can run to see what's going to be committed, and some level of >>> project consensus that this is how patches should be posted. >> >> I suggest that should be "git am", as an existing known format for email= =20 >> patch submissions, for any case except where the patch has already been= =20 >> committed (and really "git am" format could probably be used there as=20 >> well), the patch would be excessively large (whether because of large=20 >> generated files or otherwise) or the patch contains mixed character sets= =20 >> which require it to be attached in compressed form to avoid it being=20 >> mangled. We can discuss details regarding e.g. scissors lines, but I=20 >> think we should still aim for patch submissions that are valid for "git= =20 >> am" in some form - and in particular, that use "git am" markings to=20 >> separate the commit message from other remarks (e.g. differences between= =20 >> revisions of the patch) that are not intended as part of the commit=20 >> message. > > I'm fine with =E2=80=9Cgit am=E2=80=9D input, as long as there is a relia= ble way to > extract the commit, as it would be committed if you had a matching tree. > I do not want to go hunting for the matching in every case, particularly > for a series of patches. > > Do you think that the attached script might work? It does not work. We need an actual patch parser because people put random stuff before the actual patch, as suggested by the git am format. Florian