Re: [RFC] Time to talk about StringNG merge again?

Hi,
  it was easier than expected. Here's a merge bundle; it intentionally
forgets commit history, it can remain in the branch. This bundle
passes a full testsuite build on my kubuntu quantal.
It contains only what was audited so far:
- SBuf
- SBufExceptions
And I think it was audited, but I'm not sure:
- SBufStream

Left out but ready for audit are:
- cachemgr integration
- tokenizer

Should be ready but I'd like to doublecheck
- SBufList (intended to replace StrList)
- SBufUtils

Thanks!

On Fri, Mar 29, 2013 at 5:30 PM, Kinkie <gkinkie_at_gmail.com> wrote:
> Ok, it's agreed then, I'll cherrypick.
> File-wise it's not hard. I'm a bit worried about automake , but I'll manage.
>
> On Fri, Mar 29, 2013 at 4:14 PM, Alex Rousskov
> <rousskov_at_measurement-factory.com> wrote:
>> On 03/29/2013 04:46 AM, Kinkie wrote:
>>
>>> it's been a while since the last StringNG merge checkpoint , and
>>> several improvements were made in the meantime.
>>>
>>> I have briefly reviewed the previous requests for changes, I don't
>>> think there's any outstanding change requests; the new unit testing
>>> gives encouraging results (thanks Alex & Amos!).
>>>
>>> Feature branch is at lp:~squid/squid/stringng
>>
>> Well, request for changes follow requests for merge. I do not recall
>> recent requests for StringNG merge. Let's treat your email as the latest
>> request for merge. FWIW, I should be able to work on this next week.
>>
>>
>>> Questions were raised about the merge strategy - should we include the
>>> Tokenizer and additional stuff?
>>> My opinion: in order to minimize the effort, I'd like to merge
>>> everything, but marking everything but SBuf as
>>> experimental-do-not-touch or #ifdef-d out. It'd mean either a bit of
>>> unused shipped code or unused shipped files.
>>
>> My opinion on that has not changed (just like the relevant code?): We
>> should not include that code because it is of insufficient quality and
>> has not been reviewed. Removing it just before commit after patching (or
>> merging into) trunk is a minor overhead because nothing uses it. The
>> code may still remain in the StringNG branch, of course.
>>
>>
>> Cheers,
>>
>> Alex.
>>
>
>
>
> --
> /kinkie

-- 
    /kinkie