From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71737 invoked by alias); 15 Jan 2018 11:53:13 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 71723 invoked by uid 89); 15 Jan 2018 11:53:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=deadlines, cents, credit X-HELO: aev204.rev.netart.pl X-Spam-Score: 0.5 Date: Mon, 15 Jan 2018 11:53:00 -0000 From: Rafal Luzynski Reply-To: Rafal Luzynski To: libc-alpha@sourceware.org, Rical Jasan , Carlos O'Donell Message-ID: <123342723.587379.1516017189133@poczta.nazwa.pl> In-Reply-To: References: <1802414843.37687.1515744747279@poczta.nazwa.pl> <1927758682.38060.1515745107778@poczta.nazwa.pl> <49ea50a9-3cca-bbfe-8c75-41ea603d1a58@pacific.net> Subject: Re: [PATCH v12 5/6] Documentation to the above changes (bug 10871). MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Originating-Client: com.openexchange.ox.gui.dhtml X-SW-Source: 2018-01/txt/msg00502.txt.bz2 15.01.2018 09:30 Rical Jasan wrote: > > > On 01/14/2018 10:28 PM, Carlos O'Donell wrote: > > On 01/14/2018 07:42 PM, Rical Jasan wrote: > >> It seems odd not to have ABALTMON_*. Unfortunately I didn't get to > >> reviewing this sooner, and I don't want to block this, and another > >> developer has OK'd it [1], but I wanted to throw in my 2 cents. > > I asked the same thing during the review, see: > > https://www.sourceware.org/ml/libc-alpha/2018-01/msg00408.html > > > > There is no reason we can't add it in the future. > > > > Perhaps a note about this in the documentation might explain > > why the expected define is not present? > > That would be fine with me. I think it deserves a mention because the > feature is implemented, and I imagine anybody taking advantage of the > bugfix or using %OB, et al., will naturally be interested in, if not > looking for, the abbreviated equivalent. Better to have complete > documentation that gets updated later than no documentation at all. Again, as we are short of time I'll appreciate a complete excerpt of the documentation which I can just copy & paste. Or maybe better please polish the documentation later after I commit so you will get a full credit in the commit message and a changelog entry. :-) > Should the full _NL_ABALTMON list be documented alongside ALTMON, or do > you think another paragraph in the ALTMON description is a sufficient > shim? If ABALTMON is expected to be added in 2.28 because of how close > to the 2.27 release this went in, I'd prefer the latter, perhaps even > with a note that ABALTMON is expected to supersede the > currently-available _NL_ABALTMON, but if ABALTMON is intended to be > deferred until standardization, I think the former is more appropriate, > with no mention of ABALTMON. No, please don't defer this to 2.28. This set of patches has missed about 2 release deadlines already and I think it deserves to be included in some new releases of major Linux distros which I expect to be released this year. Regarding the POSIX standardization, since ALTMON_* has been accepted in ~2010 and is still not yet published I assume that ABALTMON_* will remain waiting another ~10 years (I'm trying not to be ironic, having worked on the issue for just glibc for about 2.5 years I really understand the hard work beyond standardization.) Regards, Rafal