From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by sourceware.org (Postfix) with ESMTP id 119543861834 for ; Mon, 13 Jul 2020 18:39:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 119543861834 Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-417-v4hKiTPRM92MBqMULx1zfA-1; Mon, 13 Jul 2020 14:39:01 -0400 X-MC-Unique: v4hKiTPRM92MBqMULx1zfA-1 Received: by mail-qv1-f72.google.com with SMTP id m18so7945193qvt.8 for ; Mon, 13 Jul 2020 11:39:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=5GK5FPYms5x80hhKMwTtLlcc24EIczM4e4AIbF2ptvI=; b=Q82rmJ/cG8+8S8OeQ9JdtmkVn54Mi9qeHMxKJifLhm6oyHT5jfeHK50EgftJZzLEe7 GArrc/d5bHkdwLu2xrxhtUQlz9S5/XBWbNbvPUNTWbXuVfpxY+5++1YWebrkGJieDLP7 4dOek5Zwz/ROXnQwL5yRHXbkU+zWV85fJa2QJiEgp5dMufPdGpFFDelHm9qBJoW8CQBo ExhTXpJ235zsXH+GtfAqS4FWmoM+MNC3z8BzOYunxzkmQ1oUiohBXM5TVennh24kS5+z YIrCw2Bvwo9c28s3O3/WegO2vFrZEwX8KRaqQB7Zy/17suux92bZ9IxMqIYru9We2DIb LbHA== X-Gm-Message-State: AOAM531HbPY5E8aCIPswcQtIq8Q2QFULsFWqE8ApKfPpNRiZrbGXZ6+t mwf43VdHfQFbFc1VtftFXSj0vT369DjlkE8tjvhQ3J+EJnwcREpJVcCxq+vEXNf/VIoKnV+NQyl riEwQTueFvVU6lZI3Eow2 X-Received: by 2002:ac8:47ce:: with SMTP id d14mr701197qtr.285.1594665540367; Mon, 13 Jul 2020 11:39:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw2VJK95cOB8GMSCma8H4orTxleeyDMpGxuZ6VPdk8J8wX6gbROoQzoRNTuFVyiDrB9pu968w== X-Received: by 2002:ac8:47ce:: with SMTP id d14mr701180qtr.285.1594665540164; Mon, 13 Jul 2020 11:39:00 -0700 (PDT) Received: from [192.168.1.4] (198-84-170-103.cpe.teksavvy.com. [198.84.170.103]) by smtp.gmail.com with ESMTPSA id y67sm20811114qka.101.2020.07.13.11.38.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Jul 2020 11:38:59 -0700 (PDT) Subject: Re: ABI changes still pending for glibc 2.32? To: =?UTF-8?Q?Andreas_K=2e_H=c3=bcttel?= , =?UTF-8?Q?Andreas_K=2e_H=c3=bcttel_via_Libc-alpha?= , Florian Weimer References: <2246164.obQ9GjlxrE@farino> <87h7ue2fg6.fsf@mid.deneb.enyo.de> <2135543.2JlShyGXDD@farino> From: Carlos O'Donell Organization: Red Hat Message-ID: Date: Mon, 13 Jul 2020 14:38:58 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <2135543.2JlShyGXDD@farino> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 18:39:04 -0000 On 7/11/20 12:27 PM, Andreas K. Hüttel wrote: >> >>> Medium term a backport to the older release branches would be nice. >> >> I expect that few distributions want to change locales during a >> release in this way. If you want to pick up the change, I'd suggest a >> local backport. > > Well either it's a bug, then it needs to be fixed. Or 2.30 and 2.31 are > somehow ... different? I mean, this is the whole point why I made noise in the > first place. We *should* have fixed in 2.30, but we failed to do so. The problem is now this: * When do users expect such layout to change? - Do users expect point releases to change time formatting? - Do users expect point releases to change collation sorting? - ... In Fedora we have actively avoided changing some of these things, even if they were wrong, because people were already working around the bugs and expected only to see fixes in a major upgrade e.g. dnf system-upgrade. They otherwise generally expected things to be stable in the released version. This is entirely a choice that you need to make as the downstream maintainer. I think upstream glibc should be as conservative in the release branches as the union of the downstream distros. Thus in public glibc release branches we don't generally: * Change the collation of existing strings in the release. * Change existing locales in ways which are visible and change widths, or lengths of vaious strings. Yes, it does mean 2.30 and 2.31 are special, but it also means that people can rely on their workarounds to work for all installed 2.30 and 2.31. -- Cheers, Carlos.