From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 91D97138330 for ; Thu, 11 Jan 2018 14:15:31 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4B199E0AB9; Thu, 11 Jan 2018 14:15:26 +0000 (UTC) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E690CE0AA6 for ; Thu, 11 Jan 2018 14:15:25 +0000 (UTC) Received: by mail-yb0-x22b.google.com with SMTP id b132so1124254yba.5 for ; Thu, 11 Jan 2018 06:15:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=yAndiNTN79ggWjXpbYxymnxINTeLlmtQlLrZqJ8Z6FM=; b=SVAp5sktyu0FH7guoG4sHEFgFZzRnVsV9Prm1vNZ/LVGHg0AQXBgKI7UkxarKJRz6W nNfR7z9TFSFYXrcB6TlRET8slvyv2h6cGgSkcdZvkBFuCCXwD7oeVBmD2vtKfrOzOfn1 TBsxcWm/lDDd+m0sJv3vk2hyFDRRhx1TARxr2fKBdyY3GD5/91XwWv2gZZQ9w5kJ1MVy NTATD5cp8LU20cNPto3eZRuiXM/bJHjnhb0UqYXpyqFYt8iOPlBLutJTmwA1lUTBvufO vPsXP1boK++f9f/czM/YL9kead4pMjKrggR0936sq2XGIDW8rZE5FKsitG2TAJDOz8Qg oHvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=yAndiNTN79ggWjXpbYxymnxINTeLlmtQlLrZqJ8Z6FM=; b=jgci/TKPlFyRMuJa/82KAonX6dy/yZggcHdavchams0xjCOVkAdfjZI68vu4AQe7tg XhHQFovwPrP5YfVgN5u2klqHTMKwJn+fg1ofVue6Eo5wMmgVzNj5ONoH0joIitlDRzzm Vp6r9quUvX4p1+uTrq4jAEyE/zTlrbwx1kCCCb9yAVetzI4zIavLnqQpeUGtF/fjacW6 7qLcD+vjSgQ2S0Gzi4POGav8hr0A8gljZ4sQrPhWp/D+vIp+5Qnxazww+FpPnkCWmm7P JL2KCXGMwXavBv4cXQhdxlYmMfxV8sxXUap/cRjf9H29k/7JUzG390kXTefhiKt+MfzR FG3g== X-Gm-Message-State: AKwxyteVcJT7gG3JAuLDDmf0ze3p1GQiA2xBZmjWzh5ad3tIyJ3AVboY pgal04+qK7C0PsrpvRM4ThowvbesvY1XZth9IZk= X-Google-Smtp-Source: ACJfBotrCrr7WgVJG7LuLfY+0vMHuWfgIoEv1O1z0jwiAsBSoKvQiDCReSGKvBMRPa/FASW9ME9TTs7fysn4xQ8sDVo= X-Received: by 10.37.93.6 with SMTP id r6mr1703005ybb.90.1515680124558; Thu, 11 Jan 2018 06:15:24 -0800 (PST) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Received: by 10.129.84.85 with HTTP; Thu, 11 Jan 2018 06:15:23 -0800 (PST) In-Reply-To: <87h8rtkrqr.fsf@proton.d.airelinux.org> References: <87incciwrn.fsf@proton.d.airelinux.org> <878td721sc.fsf@gentoo.org> <93D4A852-09FD-4690-8553-EBA5FEECDED1@gentoo.org> <943342a4-1d72-7da3-c985-ac3ffde2bfed@gmail.com> <197837c5-a1f4-2c2c-5027-a98af1494df2@iee.org> <87h8rtkrqr.fsf@proton.d.airelinux.org> From: R0b0t1 Date: Thu, 11 Jan 2018 08:15:23 -0600 Message-ID: Subject: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles. To: "gentoo-dev@lists.gentoo.org" Content-Type: multipart/alternative; boundary="f4f5e806488c6ae372056280c77c" X-Archives-Salt: d78adcce-4b1c-4174-8b59-5ac774d64680 X-Archives-Hash: 9724f683fb9bc8fdad17a35eb53e1406 --f4f5e806488c6ae372056280c77c Content-Type: text/plain; charset="UTF-8" On Wednesday, January 10, 2018, Benda Xu wrote: > Hi MJ, > > "M. J. Everitt" writes: > >> Not entirely as a #gentoo-nit-pick .. I'm slightly unclear on the >> different between 2.6.16+ and 2.6.32+ .. should this potentially be >> 2.16.16-32 perhaps [2.6.16~32 even] or is this more obvious only to me, >> and more confusing to others.... > > 2.6.16+ means that it can be used in any cases when the kernel is newer > than 2.6.16. For example, you can use it on linux-4.14, just with > unnecessary backward compatibility code. > > Besides, with the newest profile, kernel-3.2+, the ending kernel version > is not known. We will have to rename it when glibc jumps if the profile > is named with a version range. > I don't want to just comment on naming, but: It might be more natural to go the other way. Split profiles off based on version when breakage occurs, and otherwise do not reference a specific version. Then, the name indicates the most recent kernel supported by the profile. So remove the plus and (I think) shift all of the names "forward." So 2.6.16 becomes 2.6.32, and 2.6.32 becomes the next profile's name. This seems more natural but does change the semantics of the name. Would that be a problem? Is it expected people would want to use the profiles with compatibility features on newer kernels? This setup would prevent having to verify that old code works on new systems, which is implied to be supported.by the + naming (again, not sure if it matters). Cheers, R0b0t1 --f4f5e806488c6ae372056280c77c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wednesday, January 10, 2018, Benda Xu <heroxbd@gentoo.org> wrote:
> Hi MJ,
>
> &q= uot;M. J. Everitt" <m.j.ever= itt@iee.org> writes:
>
>> Not entirely as a #gentoo-n= it-pick .. I'm slightly unclear on the
>> different between 2.= 6.16+ and 2.6.32+ .. should this potentially be
>> 2.16.16-32 perh= aps [2.6.16~32 even] or is this more obvious only to me,
>> and mo= re confusing to others....
>
> 2.6.16+ means that it can be use= d in any cases when the kernel is newer
> than 2.6.16.=C2=A0 For exam= ple, you can use it on linux-4.14, just with
> unnecessary backward c= ompatibility code.
>
> Besides, with the newest profile, kernel= -3.2+, the ending kernel version
> is not known.=C2=A0 We will have t= o rename it when glibc jumps if the profile
> is named with a version= range.
>

I don't want to just comment on naming, but:
=
It might be more natural to go the other way. Split profiles off based = on version when breakage occurs, and otherwise do not reference a specific = version.

Then, the name indicates the most recent kernel supported b= y the profile. So remove the plus and (I think) shift all of the names &quo= t;forward."

So 2.6.16 becomes 2.6.32, and 2.6.32 becomes the ne= xt profile's name.

This seems more natural but does change the s= emantics of the name. Would that be a problem? Is it expected people would = want to use the profiles with compatibility features on newer kernels?
<= br>This setup would prevent having to verify that old code works on new sys= tems, which is implied to be supported.by the + naming (again, not sure if it matters).

Cheers,
=C2=A0 = =C2=A0 R0b0t1 --f4f5e806488c6ae372056280c77c--