Update:
  - License issue has been fixed- Thanks Rob!
  - Postinstall script is broken, Jeff and Dan are looking at it. 

Once post install is fixed, I will cut an RC

—Eric



> On Apr 6, 2017, at 2:35 PM, Dewayne Richardson <dewr...@gmail.com> wrote:
> 
> +1
> 
> On Thu, Apr 6, 2017 at 9:43 AM, Robert Butts <robert.o.bu...@gmail.com>
> wrote:
> 
>> +1
>> I didn't realize it was new.
>> 
>> On Thu, Apr 6, 2017 at 8:49 AM, Dan Kirkwood <dang...@gmail.com> wrote:
>> 
>>> +1
>>> 
>>> On Thu, Apr 6, 2017 at 7:43 AM, David Neuman <david.neuma...@gmail.com>
>>> wrote:
>>>> Since the Cookie Jar functionality is new to 2.0 and 2.0 is not yet
>>>> released, why don't we just remove the `ResumeSession` method all
>>> together
>>>> and eliminate the dependency?  Otherwise we are deprecating something
>>> that
>>>> we never formally released.
>>>> 
>>>> On Tue, Apr 4, 2017 at 2:30 PM, Robert Butts <robert.o.bu...@gmail.com
>>> 
>>>> wrote:
>>>> 
>>>>> Regarding `TC-119: traffic_ops/client dependency license issue`:
>>>>> 
>>>>> It looks like the persistent cookie jar is only needed by Traffic Ops
>>>>> Client `ResumeSession(toURL string, insecure bool) (*Session, error)`.
>>>>> Nothing in Traffic Control uses `ResumeSession`, and I doubt anyone
>>> else is
>>>>> using it. Because it returns an error, and persisted cookies have
>>>>> lifetimes, any current users already must handle errors from persisted
>>>>> cookies being expired. Thus, we can change it to always return an
>> error
>>>>> with only degraded performance (and not much, login is cheap), without
>>> loss
>>>>> of functionality.
>>>>> 
>>>>> To fix TC-119, I propose we document `ResumeSession` as deprecated,
>> and
>>>>> change it to always return an error, which lets us remove the
>>> dependency,
>>>>> without the development cost of writing our own persistent cookie
>> store
>>>>> that no one is using.
>>>>> 
>>>>> Any objections?
>>>>> 
>>>>> 
>>>>> On Tue, Apr 4, 2017 at 1:35 PM, Jeremy Mitchell <
>> mitchell...@gmail.com>
>>>>> wrote:
>>>>> 
>>>>>> These all got fixed and backported to 2.0:
>>>>>> 
>>>>>> TC-203: Mojo doesn’t set cachable headers on public files”
>>>>>> TC-190: TTL type mismatch in CrConfig
>>>>>> TC-189: ssl_multicert.config too slow
>>>>>> 
>>>>>> So Jan and Dave just need to close the issues.
>>>>>> 
>>>>>> On Tue, Apr 4, 2017 at 12:22 PM, Jeffrey Martin <
>>> martin.jef...@gmail.com
>>>>>> 
>>>>>> wrote:
>>>>>> 
>>>>>>> Hi Eric,
>>>>>>> I was going to address the immediate Postinstall issues TC-185. I
>> am
>>>>> way
>>>>>>> late on this. I created a fork yesterday, need to run a couple of
>>> tests
>>>>>> and
>>>>>>> then I can push to this fork.
>>>>>>> Jeff Martin
>>>>>>> 
>>>>>>> 
>>>>>>> On Tue, Apr 4, 2017 at 1:59 PM, Eric Friedrich (efriedri) <
>>>>>>> efrie...@cisco.com> wrote:
>>>>>>> 
>>>>>>>> We have some release blockers for 2.0. Specifically:
>>>>>>>> 
>>>>>>>> TC-119: traffic_ops/client dependency license issue
>>>>>>>>    We cannot ship with Category-X LGPL software, so I’m waiting
>>> for
>>>>>> this
>>>>>>>> to be resolved before cutting a release branch
>>>>>>>> "TC-185 post install doesn’t run due to missing perl module”
>>>>>>>>    We shouldn’t ship a release in which the install process is
>>>>> broken
>>>>>> in
>>>>>>>> this way.
>>>>>>>>   *There’s no assignee yet for this, any volunteers?*
>>>>>>>> 
>>>>>>>> I think if we can get those two taken care of we can cut an RC0
>>> later
>>>>>>> this
>>>>>>>> week.
>>>>>>>> 
>>>>>>>> Major bugs we will ship with (unless someone objects):
>>>>>>>>    TC-203: Mojo doesn’t set cachable headers on public files”
>>>>>>>>    TC-190: TTL type mismatch in CrConfig
>>>>>>>>    TC-189: ssl_multicert.config too slow
>>>>>>>> 
>>>>>>>> —Eric
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On Apr 4, 2017, at 1:13 PM, Dave Neuman <neu...@apache.org>
>>> wrote:
>>>>>>>>> 
>>>>>>>>> Good question.  I would also like to see us try to get some
>>> release
>>>>>>>>> candidates out for 2.0.  I am pretty sure the actual install
>> and
>>>>>>>>> postinstall need work.  There are also a couple of issue that
>>> are
>>>>>> still
>>>>>>>>> assigned to 2.0 and unresolved:
>>>>>>>>> https://issues.apache.org/jira/browse/TC/fixforversion/
>>>>>>>> 12338562/?selectedTab=com.atlassian.jira.jira-projects-
>>>>>>>> plugin:version-summary-panel
>>>>>>>>> .
>>>>>>>>> 
>>>>>>>>> On Tue, Apr 4, 2017 at 11:05 AM, Jan van Doorn <
>> j...@knutsel.com
>>>> 
>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> When are we planning to release 2.0? We at Comcast are
>> running
>>>>> what
>>>>>> we
>>>>>>>>>> call 2.0…. So we are +1, I am pretty sure.
>>>>>>>>>> 
>>>>>>>>>> Eric: are you waiting for something? Which cats need herding?
>>>>>>>>>> 
>>>>>>>>>> Rgds,
>>>>>>>>>> JvD
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>> 
>> 

Reply via email to