On 06/27/2012 03:02 AM, Daniel Gerzo wrote: > On 27.06.2012 10:43, Doug Barton wrote: >> On 06/27/2012 02:09 AM, Oleg Moskalenko wrote: >>> Doug, I'll post some performance figures, probably tomorrow. >> >> That's great, thanks. >> >>> But I do not agree with you that we have to reproduce the old sort bugs. >>> It makes no sense and I am not going to do that. Absolutely not. >> >> That isn't what I said. What I asked is for you to *test* the existing >> sort vs. the new one, and to report where the behavior is different. >> That's a very basic part of any sort of "replace a core utility" project >> such as this one. > > [ snip ] > > Doug, are you implying that if we were about to import a new version of > GNU sort, you would be asking for the same data? If the compatibility with the existing version were so dramatically different as Oleg claims, then yes, that would be a basic element of the replacement project. > I believe we do not > make this kind of work with any vendor code that is being updated in the > base; Au contraire, we frequently avoid updating the old versions of things we have in the base precisely because they are not bug-for-bug compatible with existing behaviors that we count on. > I do not really understand why should Oleg or anyone else do this > work when the bsdsort is compatible with a recent version of GNU sort. The first question is, where is it not compatible with the existing sort that's already in the base. The second question is, how well does it perform vs. the existing sort. I think those are perfectly reasonable questions to ask, and frankly they should have been answered before the switch was made. We already went through this with BSD grep, I hope we can avoid a repeat. DougReceived on Wed Jun 27 2012 - 08:59:13 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:28 UTC