From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94455 invoked by alias); 19 Mar 2019 22:17:42 -0000 Mailing-List: contact libc-stable-help@sourceware.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Subscribe: List-Archive: Sender: libc-stable-owner@sourceware.org Received: (qmail 94445 invoked by uid 89); 19 Mar 2019 22:17:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=H*x:Mailer, H*UA:Mailer, complains, HX-Languages-Length:1194 X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on sourceware.org X-Spam-Level: X-HELO: shared-ano163.rev.nazwa.pl Received: from shared-ano163.rev.nazwa.pl (HELO shared-ano163.rev.nazwa.pl) (85.128.223.163) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 19 Mar 2019 22:17:40 +0000 X-Virus-Scanned: by amavisd-new using ClamAV (26) X-Spam-Flag: NO X-Spam-Score: -1 Received: from poczta.nazwa.pl (unknown [10.252.0.55]) by id16c608407a.nazwa.pl (Postfix) with ESMTP id 68C5A1C1BE1; Tue, 19 Mar 2019 23:17:38 +0100 (CET) Date: Tue, 01 Jan 2019 00:00:00 -0000 From: Rafal Luzynski To: Aurelien Jarno Cc: libc-stable@sourceware.org, Paul Eggert Message-ID: <342967710.135789.1553033852674@poczta.nazwa.pl> In-Reply-To: <20190319120322.GA28833@aurel32.net> References: <20190316223151.29219-1-aurelien@aurel32.net> <1004103621.41197.1552951132012@poczta.nazwa.pl> <20190319120322.GA28833@aurel32.net> Subject: Re: [2.29 COMMITTED] regex: fix read overrun [BZ #24114] MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.8.4-Rev47 X-Originating-Client: com.openexchange.ox.gui.dhtml X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00010.txt.bz2 19.03.2019 13:03 Aurelien Jarno wrote: > [...] > In practice looking at the glibc 2.28 branch (the 2.29 has very few > commit, and most of them backported immediately after being committed to > the master branch), it appears that both practices are common. I have > attached a patch fixing the commit dates to give an example of the > impact. Now I have looked at ChangeLog in 2.28 and I agree with you. The dates look pretty random and nobody complains. I am not going to be the only one who complains, this really does not hurt me. I only (wrongly) thought this was required. In case of 2.29, as you said, there are few commits after the release so we may fix the dates or just ignore, if nobody cares. > I think we should just decide a rule, fix the wrong entries if needed, > and apply it to new commits. On my side I am undecided what is the best > option. I am undecided as well but I will not ask for an additional work for maintainers if nobody needs this. > [1] > https://sourceware.org/glibc/wiki/GlibcGit?Cherry_Pick_Changes_From_Another_Branch Thanks for this link, by the way. Regards, Rafal